• by lallysingh on 7/1/2024, 11:00:53 PM

    Wow this got really long. I was one of the coauthors for a reflection proposal (N3340) over a dozen years ago. Implementing compile-time reflection is honestly trivial - you basically transfer data from the symbol table on-demand into template specializations. It was roughly 1500 LOC to modify g++ to do it.

    Looking at the examples (https://isocpp.org/files/papers/P2996R4.html#examples) what really stands out is the direct integration of type-syntax into the language. It fits in with a certain token-substitution way that connects back to templates. It also replaces some of the uglier operators (typeof?).

    I hope it goes int! During the language's stagnation I left for a while, perhaps it'll be competitive again soon.

  • by qalmakka on 7/2/2024, 6:17:38 AM

    While I love this paper and this proposal in general, as a C++ developer every time C++ adds a new major feature I get somewhat worried about two things:

    1. how immense the language has become, and how hard it got to learn and implement

    2. how "modernising" C++ gives developers less incentives to convince management to switch to safer languages

    While I like C++ and how crazy powerful it is, I also must admit decades of using it that teaching it to new developers has become immensely hard in the last few years, and the "easier" inevitably ends up being the unsafe one (what else can you do when the language itself tells you to refrain from using `new`?).

  • by w4rh4wk5 on 7/2/2024, 7:39:25 AM

    Do I understand correctly that this proposal does not include annotations (i.e. attributes).

    More specifically, with this I can iterate over struct members and get their names and types, but I cannot attach additional information to these members, like whether they should be serialized or under which name.

    The referenced proposal P1887R1 covers this, but that's not included here, right?

    P1887R1: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p18...

  • by stefanos82 on 7/1/2024, 10:41:50 PM

    Can I ask a naive question that consists of two parts and please don't flame me? lol

      * What type of problems static reflection could solve, in general?
      * Are there specific cases and / or situations where static reflection could resolve such case, even simplify an unnecessary complexity?

  • by gpderetta on 7/1/2024, 11:10:11 PM

    I have been waiting for static reflection for the last 20 years. The current proposal seems quite nice, but the real question is whether any non trivial usage will kill compilation performance.

  • by TillE on 7/1/2024, 10:09:53 PM

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

  • by ahartmetz on 7/1/2024, 10:58:27 PM

    This looks surprisingly fine! The opaque, extensible types remind me of Win32 with its extensibility through ever new message types. The syntax looks better than expected, too - well, it's better than templates...

  • by bingo3131 on 7/1/2024, 10:09:08 PM

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

  • by pjmlp on 7/1/2024, 9:52:48 PM

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

  • by guardian5x on 7/2/2024, 9:46:23 AM

    With every new C++ feature, I can't help to think "Oh yea, cause C++ isn't complicated enough"

  • by tempodox on 7/2/2024, 2:43:52 PM

    Highly interesting, I'm looking forward to this.

    But the `member_number` functions in § 3.2 look disturbing to me. It's not discernible how invalid arguments are handled. Normally I'd look at generated assembly to answer a question like that, but this probably doesn't make sense with compile-time-fu (`constexpr`)…

  • by flykespice on 7/1/2024, 10:25:44 PM

    Has finally the committee come to reflection after decades of standard revisions and footguns? /j

  • by Dwedit on 7/1/2024, 10:04:51 PM

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

  • by kstrauser on 7/1/2024, 11:50:59 PM

    I haven't touched C++ since undergrad. Neither have I written any Qt code. But from memory, doesn't Qt's moc implement some of this stuff because it wasn't available in C++? Could this replace moc?

  • by account42 on 7/2/2024, 10:37:58 AM

    I'm not convinced that wasting a simple clean syntax (prefix unary ^) is warranted for something that should be rare outside of a few libraries.

  • by forrestthewoods on 7/2/2024, 6:32:15 AM

    I'm surprised at the positive response in this thread. I find the syntax of this beyond atrocious! My goodness C++ really does not know how to do anything simply does it?

  • by huhtenberg on 7/2/2024, 9:08:46 AM

    Oi vey. Poor C++. Look how they massacred my boy.

  • by raymond_goo on 7/2/2024, 8:09:44 AM

    Ctrl-F "networking", cry, close page...

    See also: https://github.com/cplusplus/networking-ts

  • by SilverSlash on 7/2/2024, 10:38:40 AM

    How about: Deprecation for C++26?