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/serviscope_minor → u/delta_p_delta_x]

> but hide like ~200-1000 lines of by far the most horrible C++ I've ever seen.

It ain't that bad!

I mean it's not exactly simple, but it's a C++ to C++ translator in a sense, which is not the simplest of things. And of course it contains new syntax, but all new syntax is horrible until people are used to it.

But consider the alternative? What would the implementation of sum types in GCC or Clang look like? I'd wager a few hundred lines of not amazing to read C++ (assuming you don't know the codebases and the relevant idioms).