summaryrefslogtreecommitdiffstats
path: root/docs/design/coding-conventions.md
diff options
context:
space:
mode:
Diffstat (limited to 'docs/design/coding-conventions.md')
-rw-r--r--docs/design/coding-conventions.md4
1 files changed, 2 insertions, 2 deletions
diff --git a/docs/design/coding-conventions.md b/docs/design/coding-conventions.md
index b2492685f..228b26de7 100644
--- a/docs/design/coding-conventions.md
+++ b/docs/design/coding-conventions.md
@@ -72,7 +72,7 @@ As a general rule, default to making the implementation of a type `public`, and
### Slang
-The Slang project codebase also includes `.slang` files implementing the Slang standard library, as well as various test cases and examples.
+The Slang project codebase also includes `.slang` files implementing the Slang core module, as well as various test cases and examples.
The conventions described here are thus the "official" recommendations for how users should format Slang code.
To the extent possible, we will try to apply the same basic conventions to both C++ and Slang.
@@ -132,7 +132,7 @@ Namespaces
Favor fewer namespaces when possible.
Small programs may not need any.
-All library code that a Slang user might link against should go in the `Slang` namespace for now, to avoid any possibility of clashes in a static linking scenario.
+All standard module code that a Slang user might link against should go in the `Slang` namespace for now, to avoid any possibility of clashes in a static linking scenario.
The public C API is obviously an exception to this.