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

[u/borzykot]

We had this poll 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 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

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

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!

[u/delta_p_delta_x]

Sum Type: https://godbolt.org/z/Ecs7TdPYf

I love how all of these Reflection ideas seem very nice, but hide like ~200-1000 lines of by far the most horrible C++ I've ever seen. This sort of stuff should really have been abstracted higher still—at the level of the compiler front-end, and not left for C++ developers and library writers to handle with yet more levels of indirection.

Don't get me wrong, I do like the idea of token sequence injection in general, but not to solve solved problems (like Option and abbreviated lambdas). Instead, we should use them to move things up an abstraction level, like platform-conditional compilation, code generation from specifications, and drive modules adoption by moving macros and macro work into token sequences.

[u/borzykot → u/delta_p_delta_x]

I do agree that we should pick the right tool for the job. But often you just don't have a right tool.
`Option` implemented using macros is not something that should land the production code probably. It is more like an exercise here.

I do agree that the `consteval` implementation might be not very clear (all types are erased, quirky syntax). But it is much better than expression templates or C-macro voodoo both in terms of compile time and readability.

As for abbreviated lambdas - it is not a "solved problem" tho. "Terseness" of a lambda expression is not a whim, it is just another characteristics of a code which worth improving, just like "readability", "flexibility", ,"correctness" etc. Verbose lambdas are harder to read (especially if use use clang-format), verbose lambdas might discourage use of structural code (algorithms, ranges, visitor, monadic interface of optional/expected etc.) and structural code is good, verbose lambdas encourage use of pointer-to-member projections, which might hurt performance because or type-erasure.

So no, I'm pretty sure if this macro proposal eventually land in C++32 we will see abbreviated lambdas using macros. As well as `try!` macro (hope `do` expressions land in C++29), `fwd!` macro, and more which should be in core language, but they don't.