3 ms·
Re: Should object values be captured? The results from 387 responses (to a Twitter poll) show a 2:1 preference for the value being read at the time the deferr
by apankrat 6y ago
Re: Should object values be captured?
The results from 387 responses (to a Twitter poll) show a 2:1 preference for the value being read at the time the
deferred statements are executed (66.9%) rather than when the defer statement encountered(33.1%).
Since both options - by value and by reference - may be viewed as reasonable or desirable, neither should be a default. Instead, they both should be using a special syntax. So if you write something likes this -
guard {
void * p = malloc(...);
defer free(p);
}
it simply won't compile. Instead you'd need to say something like this -
guard {
void * p = malloc(...);
defer free(^p); // evaluate now
}
guard {
void * p = malloc(...);
defer free(p^); // evaluate later
}
This may also be reused later for specifying lambda captures... should lambdas ever make their way into C.
- flohofwoe 6y agoThe ^ is already taken in context of "C lambdas" though (hoping that if C ever gets lambdas it will simply adopt clang blocks instead of a C++ like syntax): https://clang.llvm.org/docs/BlockLanguageSpec.html https://clang.llvm.org/docs/BlockLanguageSpec.html
- apankrat 6y agoAye, I've seen that. IMO it would've been better (read, cleaner) to merge lambdas and function pointers into a single language construct. Throw in the partial application too and we'd be have a natively supported concept of a "callable" instance - void foo(int tick); void bar(int tick, int tock); void do_something( void (* progress)(int tick) ); do_something( foo ); do_something( bar(,1) ); do_something( void (int tick) { /* lambda */ } ); The syntax is approximate, but for the code that is using callback-based flows this would've been very handy.
- knome 6y agoIt would be easier to execute the argument expressions immediately, as golang does. If they add this, it would be better to restrict it to the current scope, to avoid forcing the language to create complexity to handle defers created via loop in the background. Of course, that leads to the question of what to do when you loop over a defer with a goto, which would make sense if you were constantly appending function pointers and arguments to the frame similar to alloca. That could lead to fun things like a function getting inlined into a for loop and then having its defers that would have been in function instead piled together to blow the stack. They'll have to make sure they account for that in the spec and implementations. Mostly, it would be easier to remember that C should not be using such a pattern, and that if you have need of defers and various similar magic to be baked into the language and compiler, what you're doing is probably inappropriate for implementation in the C language in the first place.
- nerdponx 6y agoHopefully not with "^" though! Imagine `x^ ^ ^y`... Why not have `defer free(p)` capture at deferral execution time, and `defer free(capture(p))` capture at statement execution time?
- moonchild 6y agoI would prefer an explicit capture at the beginning of the 'defer', as in: defer[p] free(p); Instead of specifying it separately for each variable use.