4 ms·

I really don't like it. The lambda stuff, especially the captures that were ripped from C++, don't fit C at all. The question about whether it should be cleaned

by nmilo 5y ago

I really don't like it. The lambda stuff, especially the captures that were ripped from C++, don't fit C at all. The question about whether it should be cleaned up at end-of-scope or end-of-function is too ambiguous and debated. And if I'm understanding this correctly, this is the worst part: > This indicates that existing mechanism in compilers may have difficulties with a block model. So we only require it to be implemented for function bodies and make it implementation-defined if it is also offered for internal blocks. How will that work?

bangonkeyboard 5y ago
I was, and continue to be, very disappointed that the (to me) more natural and C-like block syntax for lambdas was rejected from C11 (http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2030.pdf http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2030.pdf).
- b3morales 5y ago
  In practice those signatures can get a bit tiresome to write out, but I agree, they fit much, much better with C syntax and mindset.
  - bangonkeyboard 5y ago
    Certainly, but no more tiresome than the existing C syntax for function pointers, to which they were direct analogues.
    - b3morales 5y ago
      Yes, agreed absolutely. I think they'd be used more heavily because of the convenience of allowing captures, though.
- nmilo 5y ago
  I think that idea is pretty cool. I don't like the new closure pointer type, and how all functions that take function pointers need to be retrofitted to take closures as well, but I guess it's necessary. I assume closure pointers would be implemented as a double pointer, one void* to point to the captured variables in memory, and one function pointer to point to the procedure. One of the most annoying parts of C is how callback logic needs to be defined completely separately from the calling logic.
- friend-monoid 5y ago
  I’m not sure, im no compiler programmer but I prefer not requiring an allocator like malloc and copying data and reference counting. But I don’t know.
jimjams 5y ago
Since variables can be scoped to blocks, and allocation scopes can be arbitrary, needing neither a function or block scope to bracket them, I don't see how that will fly either.
massinstall 5y ago
I agree and don’t like it either. +1

by nmilo 5y ago

bangonkeyboard 5y ago

I was, and continue to be, very disappointed that the (to me) more natural and C-like block syntax for lambdas was rejected from C11 (http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2030.pdf http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2030.pdf).

b3morales 5y ago
In practice those signatures can get a bit tiresome to write out, but I agree, they fit much, much better with C syntax and mindset.
- bangonkeyboard 5y ago
  Certainly, but no more tiresome than the existing C syntax for function pointers, to which they were direct analogues.
  - b3morales 5y ago
    Yes, agreed absolutely. I think they'd be used more heavily because of the convenience of allowing captures, though.
nmilo 5y ago
I think that idea is pretty cool. I don't like the new closure pointer type, and how all functions that take function pointers need to be retrofitted to take closures as well, but I guess it's necessary. I assume closure pointers would be implemented as a double pointer, one void* to point to the captured variables in memory, and one function pointer to point to the procedure. One of the most annoying parts of C is how callback logic needs to be defined completely separately from the calling logic.
friend-monoid 5y ago
I’m not sure, im no compiler programmer but I prefer not requiring an allocator like malloc and copying data and reference counting. But I don’t know.

jimjams 5y ago

Since variables can be scoped to blocks, and allocation scopes can be arbitrary, needing neither a function or block scope to bracket them, I don't see how that will fly either.

massinstall 5y ago

I agree and don’t like it either. +1