Reflection for C++26

#1

Post by svlasov » Sun, Jun 30, 2024, 11:26 AM UTC

Reflection for C++26
isocpp.org

Re: Reflection for C++26

#2

Post by pjmlp » Mon, Jul 01, 2024, 9:52 PM UTC

Note that there are links pointing to examples on Compiler Explorer, using the EDG and clang preview implementations.

Re: Reflection for C++26

#3

Post by Dwedit » Mon, Jul 01, 2024, 10:04 PM UTC

Compile time or runtime? Compile time reflection would be completely painless and bloat-free.

Re: Reflection for C++26

#4

Post by armchairhacker » Mon, Jul 01, 2024, 10:06 PM UTC

Dwedit wrote: post #3

Compile time or runtime? Compile time reflection would be completely painless and bloat-free.

Compile-time (“static reflection”)

Re: Reflection for C++26

#5

Post by shortrounddev2 » Mon, Jul 01, 2024, 10:08 PM UTC

Dwedit wrote: post #3

Compile time or runtime? Compile time reflection would be completely painless and bloat-free.

RTTI is a super vital feature for deserializing without having to generate code or write a ton of tedious boilerplate. I'd be very happy with RTTI in C++ and my life would be instantly easier if there were RTTI in typescript so I didn't have to use any of the hacky solutions out there for deserializing JSON on backends without RTTI.

I suppose C++'s template system might be able to generate JSON deserializers with static reflection as well

Re: Reflection for C++26

#6

Post by bingo3131 » Mon, Jul 01, 2024, 10:09 PM UTC

FYI: this is the latest draft of the proposal and it has not been voted into C++26 yet, but it is getting close.

Re: Reflection for C++26

#7

Post by TillE » Mon, Jul 01, 2024, 10:09 PM UTC

Finally. I think there have been proposals since C++17 at least, and all I really wanted is for them to solve the common problem of basic static reflection for enums (without hacks like magic_enum uses).

Re: Reflection for C++26

#8

Post by chongli » Mon, Jul 01, 2024, 10:13 PM UTC

shortrounddev2 wrote: post #5

Dwedit wrote: post #3

Compile time or runtime? Compile time reflection would be completely painless and bloat-free.

RTTI is a super vital feature for deserializing without having to generate code or write a ton of tedious boilerplate. I'd be very happy with RTTI in C++ and my life would be instantly easier if there were RTTI in typescript so I didn't have to use any of the hacky solutions out there for deserializing JSON on backends without RTTI. I suppose C++'s template system might be able to generate JSON deserializers with sta…

You don't need RTTI to deserialize data in a clean way. What you need is return-type polymorphism. Haskell has this and it makes writing serializers and deserializers symmetric and totally painless.

Re: Reflection for C++26

#9

Post by steveklabnik » Mon, Jul 01, 2024, 10:15 PM UTC

bingo3131 wrote: post #6

FYI: this is the latest draft of the proposal and it has not been voted into C++26 yet, but it is getting close.

https://github.com/cplusplus/papers/issues/1668#issuecomment...

Looks like it did very well in St. Louis!

Re: Reflection for C++26

#10

Post by fooker » Mon, Jul 01, 2024, 10:20 PM UTC

chongli wrote: post #8

shortrounddev2 wrote: post #5

Earlier quoted context omitted.

RTTI is a super vital feature for deserializing without having to generate code or write a ton of tedious boilerplate. I'd be very happy with RTTI in C++ and my life would be instantly easier if there were RTTI in typescript so I didn't have to use any of the hacky solutions out there for deserializing JSON on backends without RTTI. I suppose C++'s template system might be able to generate JSON deserializers with sta…

You don't need RTTI to deserialize data in a clean way. What you need is return-type polymorphism. Haskell has this and it makes writing serializers and deserializers symmetric and totally painless.

Return type polymorphism and inheritance doesn't mix very well.

Swift got into this mess early in it's lifecycle and it's type checking is still more expensive than the rest of the compiler combined, and unpredictable on top of that.