Problem:
Currently when printing capabilities we have a problem, we print _capability atoms.
Due to this printing, users attempt to solve capability problems using these _capability atoms.
Using _ has 2 problems for User Slang code written:
_ atoms are normally designed to only work with 1 target
_ atoms change in definition and can break user-code.
Solution:
Enforce in the capability-generator during capability creation that all _myAtom capabilities must have a corresponding myAtom capability, myAtom should be fully defined on all targets with related features.
During capability printing don't print _ if a atom is prefixed with a _
[should be a new issue] Warn any-users using a _ prefixed capability since only non _ prefixed atoms should be used.
Note: this will likely require making all _internal atoms isolated to a target and all external atoms fully defined on all targets supporting a related feature.
To reduce the complexity of a change (for easier PR reviews) the larger https://github.com/shader-slang/slang/issues/4347 task will be split into multiple smaller issues.
Problem: Currently when printing capabilities we have a problem, we print
_capability
atoms. Due to this printing, users attempt to solve capability problems using these_capability
atoms.Using
_
has 2 problems for User Slang code written:_
atoms are normally designed to only work with 1 target_
atoms change in definition and can break user-code.Solution:
_myAtom
capabilities must have a correspondingmyAtom
capability,myAtom
should be fully defined on all targets with related features._
if a atom is prefixed with a_
_
prefixed capability since only non_
prefixed atoms should be used.