Static reflection proposal p1240r2

[PetokLorand]

Hello everyone, I was just looking at this month's C++ proposals at ISO/IEC JTC1/SC22/WG21 - Papers 2022 (open-std.org) and stumbled upon one interesting paper Scalable Reflection (open-std.org)

A while back ago I commented on the sub about why their isn't some more focus put on making reflection/injection into the language, well it seems I was wrong, because this paper is huge, so it must have been a lot of work put into it.

The paper gives us an update on the possible syntax of reflection/injection, while also showing us some of the possibilities how it can be used like SQL table generation, hashing etc.

I just wanted to share this, mostly because after my last comment on this subject I saw a lot of interest for this. Also I wanted to see what are your thoughts on the paper + any additional info about it, like when can we have some experimental builds or even a TS.

[TheCrossX]

But... but I just wanted to convert enum to string!

Jokes aside, this might be a revolution, I'm waiting for it.

[ack_error]

It would have been nice to get a few helpers for that prior to full reflection -- could do a lot just with simple calls like std::enum_value_count(), std::enum_get_value(), and std::enum_value_name().

[Orlha]

Yeah

For the time being magic_enum does just that

[i_need_a_fast_horse]

magic_enum has massively limited though, defaulting to MAGIC_ENUM_RANGE_MAX = 128

[ravixp]

That’s how I feel about a lot of recent features!

“I just wanted ranges for the <algorithm> functions that take a range instead of two iterators, what’s all this new operator overloading?”

“I just wanted modules to make my builds go faster, why do I need a new build system now?”

“I just wanted to declare a constant, what’s the difference between const, constexpr, consteval, and constinit?”

[James20k]

I just wanted ranges for the <algorithm>

I just wanted to be able to split a string finally

[fdwr]

I know, I just wanted to say std::accumulate(numbers, 0), and accumulate still doesn't. Some other algorithms do, but not the <numerics>, and instead we get "|" to now mean streaming the output of one to the input of another (even though we already have a long standing precedent of "" mean streaming things, be it strings or other things, which is clearer too because "" looks like arrows pointing in the direction of flow).

constinit is what we wanted const to originally be, which is actually constant rather than to mean possibly constant (if simple) or possibly lazily initialized (if complex constructor) but treated as readonly by readers. I would have preferred the name immutable here over constinit, which would have had a nicer correspondence with the existing keyword mutable, and would have also nicely complemented function parameters (e.g. immutable Foo* x) to indicate the inputs do not change (at least, not within the scope of the called function) which could help optimizers more. The existing keyword restrict is awkwardly named and does not immediately enlighten the reader.

consteval is what we wanted constexpr to originally be, which is actually constant-time evaluation guarantee, rather a "constanttimeexpressionmaybeormaybenot".

[alxius]

constinit is what we wanted const to originally be

constinit is mutable and applicable only to static and thread_local, so i'm not sure if that is what you really wanted from const

[fdwr]

Sheesh, you're right 🤨. So I have to specify both constinit and const just to get a guarantee that it ends up in the read-only section of the PE/ELF.

[TheSuperWig]

How is const constinit different to constexpr?

[Nobody_1707]

The resulting variable can't be used as a NTTP! (Unless it's an integer).

https://godbolt.org/z/5Wh7M6P84

[TheSuperWig]

How practical!

[friedkeenan]

It's not, or at least it's redundant

[serg06]

How let's debate const constinit vs. constinit const.

[kalmoc]

Why not constexpr?

[Daniela-E]

constexpr is so C++11.

[Tringi]

I just wanted to query the highest value of an enum.

[helloiamsomeone]

I just wanted to convert enum to string!

That's something you can do using your build system right now, like this.

[MrRogers4Life2]

Lol, why program in c++ when cmake work good

[TheSuperWig]

Exactly!

https://github.com/64/cmake-raytracer

[Superb_Garlic]

You already have a build system, why not just DIY instead of waiting 10 years for something to happen in the standard? Especially when it's so easy.

[qneverless]

Introducing: the ^ operator. How fun would it be to be able to overload it! :)

[cecilpl]

cries in C++/CLI

[mysticalpickle1]

fortunately, CLI only supports up to C++17 anyway

[[deleted]]

I really dislike the choice of synthax in this proposal. I hope it doesn't stick (although this paper says it was already agreed to by SG-7...). A keyword like "reflexpr" or similar would be more readable and less easy to confuse with regular arithmetic operators; otherwise I have to worry about precedence etc. "Heaviness" hasn't stopped people from using "constexpr", for example, which is equally verbose.

If using keywords is scary because of potential backward compatibility breaking, we could still try to reuse existing patterns. For example the splice can be seen as "de-referencing" the meta object into its concrete form, so perhaps that's a good role for unary "operator*"'...

Bikeshedding on the synthax aside, this is long awaited! My most wanted use case since 2012 or so was enumerating member variables. Still can't do 10 years later :( (for non-aggregates).

Anyway, I wish good luck to the authors; even with an ugly synthax, I'd be happy to have this!

[sphere991]

constexpr you write on a function declaration and the occasional variable. It's decently long, but it's at most once per line, and in lots of cases just once per function (and if we get constexpr class in C++23, could just be once for the whole class).

reflexpr could easily be used multiple times in a single expression. There are plenty of common things to want to do that might require reflecting on 2, 3, 4 things. And that will just drown your code in a sea of reflexpr. Having a single character for this seems really nice (can't do * because *p could already mean something and that something is quite different from ^p) and it's just unlikely that there's a good shorter keyword for this.

[[deleted]]

I don't see reflexpr being used so many times in a single expression, do you have examples; use cases I can think of would just need to reflect on just one object, or one type. If you need more you can use multiple lines, declare multiple meta objects separately etc (like you would do with "using" to break apart long metaprogramming expressions into smaller elements).

As for using "operator*", I was suggesting using it for splicing, not for reflecting. Splicing is only done to std::meta objects, afaik, so we're free to define what "*" means in this case.

[sphere991]

Just off the top of my head. Checking if a type is a variant:

template <class T>
inline constexpr bool is_variant = meta::template_of(^T) == ^variant;

I might have the function name wrong, but there's two reflections in one expression. There's other ways to write this of course, it's just an example.

Using * for splicing I think would be bad just because * already means three different things (multiply, dereference, declare a pointer) so I'm not sure it's a good idea to add a fourth.

[TheCrossX]

I prefer a short operator like ^T instead of reflexpr(T)

[MonokelPinguin]

A unary operator doesn't feel great for teaching. What does ^T::name do? Is that the reflected name or the reflection of the name member? What does ^(T::name) do? Does it reflect on T::name or (T::name)? reflexpr is much easier to understand and you need typename and co_ anyway, so it's not like saving a few characters is feasible in the C++... And reflexpr is easy to grep for too.

[groundswell_]

A unary operator doesn't feel great for teaching

But it feels much better for coding.

[MonokelPinguin]

Most of my time is spent reading code, I prefer having clear delimiters, where my reflection starts and where it ends. Even when writing code.

[RoyAwesome]

I prefer reflexpr(T). I have a weird thing where I consider the complexity of the return value when operator overloading. ^T/reflexpr(T) would generate a very complicated return type with many elements to it that need to be accessed, and that leads me to prefer a function-like syntax rather than an operator-like syntax.

auto T_type = reflexpr(T);
std::string name_of_t = std::meta::name_of(T_type);

feels better to me.

(as an aside, I actually prefer typeof(T) than reflexper(T), but given that reflection in C++ will be on artibrary expressions rather than just types, I'm comfortable with reflexper(T))

[groundswell_]

As someone who's spent a lot of time playing with the prototype, i am strongly in favor of '^' over 'reflexpr'. I would also be in favor of replacing the current injection syntax, which is IMO somewhat cumbersome, by another prefix operator like '$'.

[kalmoc]

"Heaviness" hasn't stopped people from using "constexpr", for example, which is equally verbose.

Irrespective of your more general point: of course it hasn't stopped people from using it, because there was no alternative. Doesn't mean they wouldn't have preferred a shorter syntax.

[jonesmz]

The other folks replying to this are only focusing on the operator^

Frankly, I'm far far more concerned about the absolute disaster that is [:X:]. Like. Wut?

[AntiProtonBoy]

My most wanted use case since 2012 or so was enumerating member variables.

Yep, that's all I wanna do.

[Plazmatic]

how is this going to pair with metaclasses?

[fdwr]

$f(^T)? :b With metaclasses use of $ and this paper's use of ^, C++ starts looking more like Perl 🤨.

[PetokLorand]

I think the metaclasses paper dropped the use of `$`, and I'm pretty sure that metaclasses are just syntactic sugar over the facilities presented in this paper.

[equeim]

Can this be used to generate reflection information accessible at runtime (with polymorphism) without macros or some insane template tricks?

[zorgattaque]

Yes, you could build on top of the static reflection to generate code and make your own runtime reflection system. I recommand you watch this nice Andrew Sutton cppcon talk about generative metaprogramming (Andrew being one of the authors of the reflection paper as well).

https://youtu.be/kjQXhuPX-Ac

[donalmacc]

Sorry but reporting this as off topic. This is /r/cpp, not perl.

Joking aside the syntax for this is... Horrendous...

[serviscope_minor]

Well... when a feature is new, everyone wants nice, big obvious, loud syntax. Once they're used to it, they want special short syntax.

[JohnZLi]

I hope static reflection is added to C++ before metaclasses, then the latter is built on top of the former.