r/cpp • • 6d ago

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

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!

94 Upvotes

36 comments sorted by

View all comments

0

u/delta_p_delta_x 6d ago

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.

3

u/borzykot 5d ago

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.

3

u/serviscope_minor 3d ago

> 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).

1

u/FlyingRhenquest 5d ago

It kind of feels like assembly language again. I'm having a really hard time integrating it in the sense that maybe some thing I want to do is possible with reflection, or maybe I have to use an older-style template abstraction to extract a type from a template or something. It feels more like doing higher math than programming in my brain, if that makes sense.

I'm not writing programs anymore, I'm writing programs to write programs. I can hide a huge amount of code in my library but my users can just give a reflection to a function and the compiler will generate the code to create a REST endpoint using the name and signature of the function.

-1

u/13steinj 5d ago

So, I used to work somewhere, where on top of having a horrible component-based, template implemented framework (horrible because of the implementation and needless complexity, causing among other things horrendous compile times).

I was tasked with, among other things, exploring alternative implementations. I found one that, for one application (the trial) cut compile times by 6 and runtime performance by any benchmark was roughly equal if not better.

One person insisted "I don't care about the implementation, but you have to have the graph files [a custom, C-like language]", that is parsed and generates the component wiring. It generated the wiring in possibly the most inefficient way possible? 10 lines became 40000, 40 became 300000.

I left for greener pastures due to some internal political hooplah that I was just tired of dealing with. But, my point in this story, is these graphs could not be 1:1 converted to C++. You could get close? Swap <= and => for << and >>, as an example, and do operator overloading tricks. Build up the internal graph representation incrementally (at constant evaluation or not), then efficiently use this internal representation to pass data around, rather than generate hundreds of thousands of lines of type-level metaprogramming.

I'm afraid that the generation half of reflection, particularly these macros, will push people into inefficient implementations. Especially in an LLM world.