3 ms·
Interesting idea but I have some issues with the code style here. Two problems I see are implicit casts from pointers to integers and use of func() instead of f
by moody__ 3y ago
Interesting idea but I have some issues with the code style here. Two problems I see are implicit casts from pointers to integers and use of func() instead of func(void). These are both somewhat minor complaints but they tend to lead to bugs when tested in other environments. In this case I would expect a project aiming to be "C but safe" would at least take the maximum use of existing C safety features. Also the annotations seem a bit cumbersome, I know that's easy to say without providing an alternative but something just doesn't sit right with me about how verbose they are.
- akiarie 3y agoInteresting points. Because it's easy to do the type checking at compile time for function prototypes (though we haven't implemented it yet) we haven't felt under pressure to use the `func(void)` notation, which has always felt somewhat uncouth to me. The verbosity of the annotations is the most jarring thing at the beginning. However, do you find any of them unclear? Because we're optimising for similarity to C before terseness.
- moody__ 3y agoI don't find them unclear at all, after reading the introduction I felt pretty comfortable with everything that was going on in the examples. I think this type of approach you're going for can work depending on how it grows to cover more complex cases like loops. I'll be keeping tabs on how your work progresses.