PostI've tried "Token Sequence Injection & Modern Macros" and here are my thoughts

I've tried "Token Sequence Injection & Modern Macros" and here are my thoughts We had this [poll](https://www.reddit.com/r/cpp/comments/1wlggmv/comment/pb3tkrr/) recently here on r/cpp about community expectations and most desired features in C++29 and in future C++ revisions in general. My answer was: * abbreviated lambdas * algebraic types But I do understand that those features won't hit C++ probably ever. But then we had this [post](https://www.reddit.com/r/cpp/comments/1wq2jld/token_sequence_injection_modern_macros_the_most/) about Token Injection and *Modern Macros*. Wait a minute, modern macros? Never heard about this proposal... And you know that? We probably won't need to wait for neither abbreviated lambdas, nor algebraic types in core C++. We can just add them ourselves using those macros with very little boilerplate. Abbreviated lambdas: [https://godbolt.org/z/a8d9a6f19](https://godbolt.org/z/a8d9a6f19) namespace stdv = std::views; namespace stdr = std::ranges; std::vector<vec2> points = {{2, 67}, {2, 42}, {3, 666}}; std::vector<int> ys = points     | stdv::filter(fun!(p => p.x % 2))     | stdv::transform(fun!(p => p.y))     | stdr::to<std::vector>(); stdr::sort(points, fun!(|l, r| => l.y < r.y)); stdr::sort(points, std::less{}, fun!(p => p.x)); *fun,* isn't? Sum Type: [https://godbolt.org/z/Ecs7TdPYf](https://godbolt.org/z/Ecs7TdPYf) sumtype!(option<T> {     some(T),     none, }); option<int> opt = some(10); opt = some(22); opt = none; Pattern matching isn't there, but you could imagine something like: // match!(<you can put any tokens here!>); auto x = match!(opt, some(x) => { x.call_method() }, none => { 55 } ); Basically you can come up with any syntax you like. When I was exploring the possibilities of this proposal I couldn't shake the feeling that I'm reimplementing parts of the compiler which aren't there for some reason. Like you literally can look at "sumtype" implementation and see that this is basically a parser of arbitrary syntax that you came up with and translating it into C++... Superpowerful and a bit scary... We used to reimplementing some core library features which were missing from the Standard Library for quite some time. `optional, variant, algorithms, smart pointers` and now `async task`. All of that should have been in the Strandard Library from day 1, so that other libraries can use this lingua franca and interoperate with each other. And now we are repeating same thing but on a very different level. Now we are going to allow adding not only library features, but *language* features. I 100% guarantee, that each team will have their own, slightly different syntax for abbreviated lambdas, because it is so much more expressive and terser and more readable. Don't know about you but I always find myself in the situation where I better use plan old for loop instead of structural views/algorithms, because the latter is so much more verbose and unreadable because of lambdas, **especially after you apply clang-format on it**... And now you have: fun!(lhs, rhs => lhs.x < rhs.x); lambda!([&](lhs, rhs) -> lhs.x < default); lm!(|lhs, rhs| => lhs.x < rhs.x); All of this is perfectly implementable using this Modern Macros proposal in less that 100 lines of code. Committee may have perfectly reasonable arguments of why it is impossible to add abbreviated lambdas into C++, but the community clearly is asking for that feature for ages, and it will be in every future codebase, but with slightly different implementation... On the other hand Rust language do have these macros for ages now, people do abuse them in some very clever ways (select operator from golang, inline HTML, etc.) and the world ain't collapsed. We'll see! https://redd.it/1wqyuh0 @r_cpp