-
Notifications
You must be signed in to change notification settings - Fork 1
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
My initial thoughts #2
Comments
The key difference between this transition and the 2 -> 3 transition is that modules are independent. With the new C-API,
I hadn't seen your draft (or if I had, I've forgotten). Are there any specific goals you want to add that aren't included in the design pricinples?
Macros and inline function are OK in the API, as long as they are just convenience wrappers around ABI functions. More so, if they are automatically generated. To support Rust (for example), we generate the equivalent Rust code. No bit fields, though.
My current thinking is that the class would be created declaratively from a layout and inheritance description, then methods and properties would be added procedurally.
It's a description not a name. |
My mistake, enums are not defined to be the same size as ints. |
The macros/enums/bitfields is the main point. (I appreciate your addition of va_args to that list.) After consulting my notes on language interop I have another suggestion. Other languages have issues working with sizes of C integral types, so we should limit which ones are used more than just “Use standard C99 types”.
And by No invalid states, casting such an argument to enum will usually need a range check.
Yup, reading more of the proposal, this makes sense for many cases. I'll revisit when things are more fleshed out.
And one more:
This is surprising. Won't all the NULL checks hurt performance? Generally I'm not on board with all the tradeoffs -- the other big one for me is “passing the interpreter to each API function” vs. performance, which limits us to platforms with fast per-“thread” storage. I guess that's also for a separate discussion. |
Yes, lots of The issue of whether to use thread-local storage or to pass an explicit parameter does need more discussion. |
In C++ and the upcoming C23 standard there are ways to declare the underlying integer type for an enum which would solve this. We just have to wait a long time before we can actually use this :-( |
That's entirely your call. I listed what you might want to consider, but this is your proposal, so I stay away from arguing points we disagree on. |
I don't know how discussions are supposed to work here, so I'm sending these as an issue:
The text was updated successfully, but these errors were encountered: