I started out trying to write something like the OP, but changed direction when I convinced myself there would have been no sane way to implement member call syntax. I honestly can't decide if it's cursed or genuinely useful (minus the unicode name, that's cursed).
As if C++ didn't have enough of “black magic” already, there's another layer of that. Just in case you find error messages involving template applications still too readable.
Little reminder that there once was a "C++ error message competition" [0] where your score was measured as "the size of the error message divided by the size of the source code". The winning entry had a score of 5.9 billion.
It's a common extension but it's not standard. Both C23 and C++23 only allow identifiers to start with a Unicode XID_START character, which excludes $. And with older standards, it was just Latin letters, the underscore, and explicit \u escapes.
If you look in the project's pedantic.cmake, you'll find a add_c_and_cxx_compile_options("-Wno-dollar-in-identifier-extension") just to suppress warnings about this.
Once you strip out all the helper code for tuples and args, it's really not the worst. Made sense to me on the first read. Sensible naming and not that much metaprogramming indirection going on, thank god.
Or maybe I am too brainwashed by C++ at this point.
huh. very cute. in the past, i had an idea for terser lambda syntax, similar to C#'s expression body functions - which i did end up implementing in clang:
auto sum = [](auto a, auto b): a+b;
but this is something else. i didn't think i'd like it at first, but actually i think i might be coming around to it. the.. dollar syntax is regrettable, although it's not a show stopper.
I'm sorry I know this is horrific but I still love it. This looks like a better version of Boost Lambda2. I would potentially maybe replace `$` with `_` before using this (which should be easy as a layer) like Boost::Lambda2 but otherwise I'm excited to use it. Not that I would use anything like this in production, but it looks too fun not to play around with.
Pretty cool. I was wondering what kind of arcane magic they used to get $xxx working, since $ is not a standard identifier char... then I realised they straight up define $arg, $call, etc as constants (makes a lot of sense). And $ really is not an identifier char by the Standard, but evidently some compilers accept it.
Another idea in this vein, but with a surprisingly straightforward implementation (27 lines): https://github.com/GrantMoyer/lambda_hpp
I started out trying to write something like the OP, but changed direction when I convinced myself there would have been no sane way to implement member call syntax. I honestly can't decide if it's cursed or genuinely useful (minus the unicode name, that's cursed).
As if C++ didn't have enough of “black magic” already, there's another layer of that. Just in case you find error messages involving template applications still too readable.
Little reminder that there once was a "C++ error message competition" [0] where your score was measured as "the size of the error message divided by the size of the source code". The winning entry had a score of 5.9 billion.
[0] https://tgceec.tumblr.com/post/74534916370/results-of-the-gr...
2014 but still hilarious, although the winner had nothing to do with templates.
From one of the entries:
> Extra credit for using Perl, which is the only language less readable than C++ templates.
Looks cursed to me.
But TIL dollar sign $ is also valid character for identifiers.
> $ is also valid character for identifiers.
Has been like that in C since forever.
It's a common extension but it's not standard. Both C23 and C++23 only allow identifiers to start with a Unicode XID_START character, which excludes $. And with older standards, it was just Latin letters, the underscore, and explicit \u escapes.
If you look in the project's pedantic.cmake, you'll find a add_c_and_cxx_compile_options("-Wno-dollar-in-identifier-extension") just to suppress warnings about this.
VMS used $ - eg
That might be why GCC originally included $ support.Neat. Reminds me of https://github.com/dry-python/lambdas
I've always thought this should be first-class syntax in any language with lambdas
That's horrifying
To be honest the implementation looks surprisingly readable… at least compared to other horrors like the standard library implementation.
While there are some new rules regarding arguments naming, the new syntax doesn’t feel more complex than the default lambda syntax.
So all in all I would say the most horrifying thing here is the fact that the language allows such extensions in the first place ;)
Once you strip out all the helper code for tuples and args, it's really not the worst. Made sense to me on the first read. Sensible naming and not that much metaprogramming indirection going on, thank god.
Or maybe I am too brainwashed by C++ at this point.
huh. very cute. in the past, i had an idea for terser lambda syntax, similar to C#'s expression body functions - which i did end up implementing in clang:
but this is something else. i didn't think i'd like it at first, but actually i think i might be coming around to it. the.. dollar syntax is regrettable, although it's not a show stopper.I'm sorry I know this is horrific but I still love it. This looks like a better version of Boost Lambda2. I would potentially maybe replace `$` with `_` before using this (which should be easy as a layer) like Boost::Lambda2 but otherwise I'm excited to use it. Not that I would use anything like this in production, but it looks too fun not to play around with.
Pretty cool. I was wondering what kind of arcane magic they used to get $xxx working, since $ is not a standard identifier char... then I realised they straight up define $arg, $call, etc as constants (makes a lot of sense). And $ really is not an identifier char by the Standard, but evidently some compilers accept it.
I fail to see the benefit from the lens of C++23.
Isn’t this basically the obsolete Boost.Lambda?
It's like Boost Lambda2 or Boost HOF. Boost Hana also has a similar feature.
This seems to be more fully featured than all of those though. Maybe some could be ported over to Lambda2.
Not really a new idea. These are expression templates: https://en.wikipedia.org/wiki/Expression_templates
[dead]
[dead]