You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The existing "Spire" code made heavy use of namespaces, but that just complicates what we are trying to accomplish in a lean-and-mean codebase.
I'm not 100% decided on what an ideal convention should be, but my first stab would be:
All user-face C++ interfaces (currently just inline wrapper stuff around the C API) will reside in the slang namespace
All implementation stuff will reside in the Slang namespace (notice capitalization) with no nesting.
If we really need multiple namespaces (e.g., multiple back-ends need types with similar names), then it probably makes sense to give each a distinct top-level namespace with a Slang prefix, just to keep things flat.
I'm not enamored of having a distinct namespace for public API vs. private implementation. I might advocate for finding a different way to expose the API that avoids the need for the opaque wrapper types, so that we can actually expose the same namespace and type names (potentially making Slang more debuggable for client code).
The text was updated successfully, but these errors were encountered:
The existing "Spire" code made heavy use of namespaces, but that just complicates what we are trying to accomplish in a lean-and-mean codebase.
I'm not 100% decided on what an ideal convention should be, but my first stab would be:
All user-face C++ interfaces (currently just
inline
wrapper stuff around the C API) will reside in theslang
namespaceAll implementation stuff will reside in the
Slang
namespace (notice capitalization) with no nesting.If we really need multiple namespaces (e.g., multiple back-ends need types with similar names), then it probably makes sense to give each a distinct top-level namespace with a
Slang
prefix, just to keep things flat.I'm not enamored of having a distinct namespace for public API vs. private implementation. I might advocate for finding a different way to expose the API that avoids the need for the opaque wrapper types, so that we can actually expose the same namespace and type names (potentially making Slang more debuggable for client code).
The text was updated successfully, but these errors were encountered: