-
Notifications
You must be signed in to change notification settings - Fork 49
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Confusing semantics of (var extern type) #203
Comments
Thanks for this. There wasn't documentation for this (now updated), but the semantics here are intentionally the same as in C:
|
C needs this semantics because C doesn't have the concept of modules. In C, to use global variables from another compilation unit, an Is there something I missed, that makes this semantics consistent to C is important? |
The C consistency is mainly to limit surprise for people who are used to C, and to allow people to use C-like approaches to things if that's what they'd prefer. There are some exceptions to this, like the general lack of implicit casting, but it's mostly very similar. I think the arguments in favour of C consistency here are compelling:
|
I think this sentence expresses your intention very well, and now I can understand it. I have been always finding the various kinds of linkage of Dale confusing. The confusion seems to come from the interaction between C linkage and the module system, but I am not sure what to suggest now. I am going to use Dale more, and to give this issue more thought. |
I expect
x
is defined in this module with an uninitialized value. But the compiler complains about missing symbols instead.I expect
extern
variables have the same semantics withextern
structs and functions, i.e. defined in the module and visible to other modules.The text was updated successfully, but these errors were encountered: