4 ms·
C could really use a standardized defer feature. I don't like the proposed syntax though, because it introduces a new meaning for the & operator. In all other
by nrclark 5y ago
C could really use a standardized defer feature.
I don't like the proposed syntax though, because it introduces a new meaning for the & operator. In all other uses, the & operator modifies the type of the operand, to be the opposite of the * operator.
In the proposed syntax, & becomes something a little bit different: a C++-style reference. I think it would introduce too much language confusion.
A more C-like syntax would be:
defer(captures-by-value; captures-by-reference) {}.
Defer() statements would be executed at scope-exit, in last-in first-out order. Standard block scoping would apply for anything declared inside of the defer().
- KerrAvon 5y agoThe & syntax builds on a separate proposal for C++-style lambdas in C which would introduce that syntax generally.
- pantalaimon 5y ago+1 We are not using teletypes anymore, the days of confusing single character keywords should truly be over.
- isaiahg 5y ago> Defer() statements would be executed at scope-exit, in last-in first-out order. Standard block scoping would apply for anything declared inside of the defer(). But this still doesn't address the problem the change is used to contain. Should defer free a variable's value as it is when defer is used or the value at the end of the scope. And is it really such huge change. I don't find it too far removed that it becomes confusing and I appreciate the additional control over what should be freed and where. You can imagine a scenario where a variable is being reused multiple times where this kind of additional control might be useful.
- nrclark 5y agoThat's the capture-by-reference vs capture-by-value distinction in a nutshell, yes. Capture-by-value takes a snapshot of the value instantly, and stores it until the block is executed. Capture-by-reference waits to evaluate the variable until the block is executed. Between the two, capture-by-reference is the least surprising behavior IMO. It acts like the deferred code is copy/pasted onto the end of the function. Capture-by-value is the most flexible, and can also emulate capture-by-reference by using pointers. Any syntax should either support both, or only capture-by-value.
- yason 5y agoI like your C-like syntax better. But I don't think there's any need to differentiate between different captures. Capture by value is enough because what do you need in C if you need a reference? Capture the value of the pointer. { void *chunk = malloc(x); defer (chunk, void **reference = &chunk) { ... } ... } This would allow you to operate on the value both from the defer declaration time and defer execution time, whichever it is that you need.
- nrclark 5y agoThat's an interesting point, and very C-like. You're right that capture-by-value can emulate capture-by-reference. Capture-by-value does have a weakness though, in that it requires allocation (whether stack or heap). Capture-by-reference doesn't have any storage overhead. In my example, I suggested having both. But if we had to pick only one, capture-by-value would be the one to use.
- krapp 5y agoI disagree. Every programming language is suffering from bloat and complexity now. We need one language, at least, to stand up against the madness and remain simple and stupid, even to the point of being dangerous - the old man yelling yelling at clouds of programming languages. That language could have been javascript, before all the nonsense with classes and templates and integers, but now maybe it should be C. Like, C doesn't even know what a string is, and I respect that. What even is a "string?" Sounds like unnecessary complexity to me. Raw pointers and bytes should be enough for anyone.