feat: add extern keyword and documentation #29

Merged
noClaps merged 2 commits from feat/if/extern into main 2026-07-10 11:33:48 -04:00
No description provided.
feat: add extern keyword and documentation
All checks were successful
/ deploy (push) Successful in 53s
1d8f4dfbec
Signed-off-by: Insidious Fiddler <me@codycody31.dev>
noClaps left a comment

I think you can remove the Implementation formats section, since those details are really up to the compiler rather than being part of the language spec. You can add a sentence or something somewhere saying that extern functions can't be type-checked by the NC compiler so any issues during compilation will be reported by the compiler backend, since that seems to be the gist of that section, unless I'm misunderstanding it.

I think you can remove the `Implementation formats` section, since those details are really up to the compiler rather than being part of the language spec. You can add a sentence or something somewhere saying that extern functions can't be type-checked by the NC compiler so any issues during compilation will be reported by the compiler backend, since that seems to be the gist of that section, unless I'm misunderstanding it.
@ -0,0 +39,4 @@
The implementation file's extension selects the handler used by the compiler. This keeps `extern` independent of any one external format. A compiler may support `.etch` or other formats without changing NC syntax.
The supported extensions are compiler-specific. A compiler must report an error when it does not support the extension in an external block. Paths without an extension refer to NC modules and are loaded with [`import`](../modules).
Owner

Paths without an extension refer to NC modules and are loaded with import.

I don't think that necessarily has to be true. The compiler should try to compile it regardless of what the path or extension is, and if compilation fails then it can report that error. But it's perfectly legal to have

extern "path/to/file" as file {
  // ...
}

without an extension and have path/to/file not be an NC file.

> Paths without an extension refer to NC modules and are loaded with [`import`](../modules). I don't think that necessarily has to be true. The compiler should try to compile it regardless of what the path or extension is, and if compilation fails then it can report that error. But it's perfectly legal to have ``` extern "path/to/file" as file { // ... } ``` without an extension and have `path/to/file` not be an NC file.
insidiousfiddler marked this conversation as resolved
@ -0,0 +41,4 @@
The supported extensions are compiler-specific. A compiler must report an error when it does not support the extension in an external block. Paths without an extension refer to NC modules and are loaded with [`import`](../modules).
Each format handler defines which NC types it can represent at its boundary. If a handler cannot represent a parameter or return type, the compiler must report the declaration as an error. This check applies to compound types such as structs and maps as well as builtin types.
Owner

I don't really understand what this paragraph means.

I don't really understand what this paragraph means.
insidiousfiddler marked this conversation as resolved
refactor(extern): cleanup and fix the areas noClaps brought up
All checks were successful
/ deploy (push) Successful in 57s
a6faacbf77
Signed-off-by: Insidious Fiddler <me@codycody31.dev>
noClaps approved these changes 2026-07-10 11:33:22 -04:00
noClaps left a comment

LGTM

LGTM
noClaps deleted branch feat/if/extern 2026-07-10 11:33:57 -04:00
Sign in to join this conversation.
No reviewers
No labels
stdlib
syntax
No milestone
No project
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
nclang/design!29
No description provided.