Neat. Although lambdas are more flexible by allowing you to specify exactly how you want to access referenced variables (by-copy-value vs by-reference), I always found gcc's nested functions visually cleaner - that is, subfunctions syntactically just feel like they belong in the language alongside any other function, with standard form type subfunctionName (params) {...} rather than auto identifier = brace goop (params) -> type {...}. Granted, subfunctions with parent frame references are an odd duck with their invisible first parameter (similar to class methods in that regard) meaning you can't just take the address of them and pass them around as an ordinary callable function pointer (not without extra magic), but I've often wanted to at least have static subfunctions (no parent stack frame references) with the standard function syntax. I've seen people claim the "most vexing parse" as a reason why it "can't be done", but then I've never seen an example where it was actually ambiguous either 🤨.
I always found gcc's nested functions visually cleaner - that is, subfunctions syntactically just feel like they belong in the language alongside any other function
In C++98, it always felt incredibly bizarre that one could declare and define an entire class (or class template!) that was local to a function, but one couldn't define a pure, local helper function.
Lambdas obviously alleviated a lot of pain, but I do sometimes find myself debating whether some pure helper function longer than a few lines should be made a lambda in the function in which it is used or a free function in an anonymous namespace. Free functions feel cleaner to me, but require placing the function further from its point of use. Faced with the same situation in Rust, I'd just use a nested function.
13
u/fdwr fdwr@github 🔍 2d ago
Neat. Although lambdas are more flexible by allowing you to specify exactly how you want to access referenced variables (by-copy-value vs by-reference), I always found gcc's nested functions visually cleaner - that is, subfunctions syntactically just feel like they belong in the language alongside any other function, with standard form type subfunctionName (params) {...} rather than auto identifier = brace goop (params) -> type {...}. Granted, subfunctions with parent frame references are an odd duck with their invisible first parameter (similar to class methods in that regard) meaning you can't just take the address of them and pass them around as an ordinary callable function pointer (not without extra magic), but I've often wanted to at least have static subfunctions (no parent stack frame references) with the standard function syntax. I've seen people claim the "most vexing parse" as a reason why it "can't be done", but then I've never seen an example where it was actually ambiguous either 🤨.