Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
use a builtin enum for calling conventions instead of keywords #661
right now we have these keywords for function calling conventions:
If no calling convention is specified, then the calling convention is selected automatically (and currently defaults to the "fast calling convention" that LLVM has available.) Related issue: #105 when mixing automatic calling convention with specified calling conventions.
This proposal is to make a builtin enum:
And instead of keywords, the
If a calling convention is not specified,
Then it becomes easier to add reflection such as
It would probably serve this proposal to automatically import the
Other keywords such as
I like this. Extra keywords can come back and bite you later.
Java has annotations. Nim has odd looking pragmas etc. It seems like a good idea to have some way to apply metadata/modifiers to things without cluttering up the keyword set.
I like where you are going with this.
I like where this is going, but I don't see what other uses an enum annotation has for functions other than the calling convention. If you're going to introduce the notion of "you can annotate functions with enums", it better have more than one use case.
I think this can be applicable to other function attributes, such as
This was something I was wondering about a little while back so I generally like the proposal.
I think it'd be wise as @phase mentioned on looking at the
We already expose some of these at the language level (such as align) and others aren't applicable to zig, (i.e. non-null). I can see more attribute like functionality wanted in the future, in which case we would need a system to handle many attributes.
The more keywords you have the more you have to watch your variable names etc. If you have multiple namespaces (i.e. struct field names do not collide with other names), then it is not so bad. Translating C to C++ can be "fun" sometimes because of the reserved words.
referenced this issue
Jan 11, 2018
added a commit
Jan 23, 2018
added a commit
Mar 21, 2018
This was referenced
May 4, 2018
I'm into it. If you do it, I'd definitely support using this bracket notation over parentheses for struct/union modifiers too, for consistency and intuitiveness. It's cool that whatever is inside the brackets is a comptime expression.
Just to add to that list for inspiration, Rust has attributes, which have some usability drawbacks in my opinion:
Nitpick: this should probably be