Reflection in C++ - Past, Present, and Hopeful Future - Andrei Alexandrescu - CppCon 2022

[@piotrarturklos]

There is a paradigm that Andrei has proposed before, especially in the context of D programming language, called "design by introspection" and is exactly the reflection use case that he describes in the first half of this talk. I'm glad that he thinks that it can be done in C++ as well. Excellent work! It's also great that this talk compares C++, D and Rust.

[@mixfaa]

Awesome, compile time reflection, cpp is great

[@ultradude5410]

A fantastic talk as always! Andrei always delivers informative talks in an easily understood way! I can't wait for static reflection to be fully-baked and available for use!

[@BalanNarcis]

I'm a bit sad that Andrei did not have this talk in person 😥.

[@mrlithium69]

Andrei is always great

[@BalanNarcis]

Amazing feature! I can't even begin to imagine the kind of libraries we can write using something like this!

[@arcticnomad8723]

Billions and billions of people watching offline :D Gotta love Dr Andrei's confidence :D

[@DbugII]

The point about std::stack is so true. It's extremely rare that you can afford to use just a pure stack where only the top element can be manipulated, it's ultra frequent to have the need to check the top but also top +1 or top +2 to know if you need to for example perform an operation. I always ended up using a vector or a dequeue instead.

[@PaulSkeptic]

Thank you! Value based reflection FTW!

[@LogicEu]

His talks are amazing, and this one is no exception

[@kyoai]

Quite interesting talk, thank you! However, I must say that I am not a big fan of the proposed operators ^T and [:e:], because the latter one is significantly more complex to type and ^ already has other meanings. I wonder if it wouldn't be possible to just use the so far unused '$' for both : $T gives meta::info value and $e, if e is a meta::info value, just gives back the template name/type. $$T is T while $$e is e. Also, it would be a lot easier to type.

[@schulmastery]

can't believe he made it an hour without throwing due shade at concepts

[@dmitriidemenev5258]

29:52 It's nice that Rust allows you to do exactly that! 45:51 To be more specific, procedural Rust macros come in several flavors and each of them has their their strengths and limitations. Derive macros can only insert new tokens into the AST. Attribute macros can rewrite the tokens corresponding to an item but both input and output code still should be an item in Rust (it can't be `struct MyStruct {` because it requires a closing brace). Even function-like (the most powerful) Rust macros can't produce `struct MyStruct` but they can accept nearly arbitrary syntax.

[@IvanLeben]

I really hope the "compile time for loop" ends up having the syntax "for constexpr" for consistency with "if constexpr" rather than "template for (constexpr" (and the syntax would signify that everything inside the for () brackets should be constexpr). C++ really seems to have a knack for overly wordy, inconsistent syntax. For example, compare the general template syntax to other languages like Rust, Zig, Odin, or Vale. I get the whole thing about decades of legacy and all, but that's one of the things that makes C++ code consistently less readable then other modern languages.

[@llothar68]

That’s why Herb Sutter is working on an alternate syntax solution.

[@JohnDlugosz]

My impression is that it's intentionally different because it works differently. `if constexper` and `for constexpr` must appear where you can have a statement, and it introduces a scope. `template for` does not introduce a scope, and can appear in the middle of a `class` definition to add a member. And a `template for (f(e))` where `f` is a consteval function that returns a list of one item if e is true and a list of 0 items otherwise would be functionally identical to a `template if`, though without an `else` clause. Now recall the huge discussion around `if constexpr` some years ago. The introduction of a "static if" language feature in a way that would work for C++ gave us the limited `if constexpr` even though having a more general `template if` that could introduce declarations was on the table, and Andrei was certainly lobbying for it. It would pay to revisit the rationale for what was decided on. I'm sure it has some rational based on existing compiler implementation and what could be confidently and correctly implemented in a short time.

[@GhassanPL]

This video comes on the heels of the announcement that the current conservative estimate for reflection in C++ is C++29, in 6 years.

[@Raspredval1337]

but what if we can have a scope AND a keyword to export or inject the definitions of this scope into an outer scope? It can complicate the lifetime of the injected thing, but still, it's a nice way to reuse existing statements instead of making new stateless versions of the statements

[@andreaallais4942]

"never use public inheritance against a value type" at 18:16 Why is that discouraged?

[@martinba9629]

Slicing

[@Knitschi656]

@@martinba9629 But wouldn't that be only a problem if tainted_string added some member variables to string? If you do not want to change the class you should be fine right?

[@orbital1337]

@@Knitschi656 When you're inheriting from a value type, you almost never want an "is a" relationship but rather an "implemented in terms of" relationship. Thats public vs private inheritance. Slicing is not the only problem but rather just a symptom of using the wrong type of inheritance. Public inheritence or "is a" inheritance implies that you can substitute the derived class for the base class. This is a baaaaad idea. For example, in our case of the tainted_string which publicly inherits from std::string, any function which accepts a std::string will now accept a tainted_string making the whole thing completely pointless. Quick, if "s" is a tainted_string what type does "s + s" have? Or in the example where you have a bound_checked_vector that publicly inherits from std::vector, any function which accepts a std::vector now accepts your bound_checked_vector but *bypasses the bound checking*. Is that really what you intended? Also, did you check that you actually bound-checked every single relevant member function? Oh you did? And when your team updates to C++23 you're going to remember to go back to this class and add a bound-checked version of "insert_range" right? Yeah probably not. When you inherit from something that wasn't designed to be inherited, your code becomes very brittle and susceptible to undefined behavior. That holds even for private inheritance to some degree but *especially* for public inheritance. You're letting somebody else's code just affect the API of your class in ways that you have no idea about.

[@csibesz07]

Why did it take so long to introduce proper compile time reflections? Also the syntax looks over complicated, oh well.

[@zofe]

Language =defined= reliable (=fixed) means of communications.

[@ВалерийРодин-б9т]

Very interesting! but why can't you do something like Qt's meta-object system, based on the QObject base class or similar java object ? Or does the inheritance approach have some problems?

[@KulaGGin]

_"Qt's meta-object system, based on the QObject base class or similar java object"_ This would just be runtime type information. What is presented in this talk is ability to query, process and generate code at compile time. C++ needs compile time reflection, so we can get rid of all the preprocessor crimes everyone been committing for 43 years. Also, the Qt uses preprocessor to implement these things. With the addition of reflection to C++, Qt will be able to use it to implement its things instead of macros.

[@player-eric]

Could you please provide the accurate subtitles for this video?

[@benjaminshinar9509]

very interesting talk, i work with C# and sometimes I use the reflection facilities there, but it's mostly for unit testing code, and never for serious stuff. (and it's runtime, not compile time) I didn't understand the part about introducing scope, can someone clarify the problem?

[@grigorij81]

Dynamic reflection akin to available in C# is not suitable to many domains where C++ is used. But even C# currently slowly moves towards compile time reflection/code-generation. In general reflection is more suitable for library code and it used a lot in .NET under the hood: all the various XML and JSON serializers, all the design-time support for UI components is done by reflecting user types and querying attributes attached to them. If static reflection comes to C++ it would be used for the same kinds of tasks

[@shikyokira3065]

​@@grigorij81 Exactly. I have been writing my own ORM and reflection is the literally the core technology making it possible and I would love to bring it do C++ as well. And if they are bringing reflection, might as well bring custom attribute too

[@lukasz2345]

2.1 Billion of Billions so far ;)

[@PaulMetalhero]

I think C++ should have an official Python-inspired scripting language

[@salvoilmios]

This feels like it should be illegal

[@abhashkumarsingh2673]

pdf for this video is not available.

[@thelatestartosrs]

i dont agree with the notation, type to meta should be similar to decltype

[@Carutsu]

The syntax is absolutely atrocious. What happened to Herb's syntax? It was actually made for humans

[@player-eric]

[Finished]: 2.5 Stars I think this video is not that friendly to a C++ beginner like me. The advice the speaker gave do not come with specific examples of the current C++ usage, so I could not fully understand the necessity of adding these features. I hope more code examples can be given to describe these thoughts.

[@zxuiji]

24:50, sounds like you finally learned how bad it is to focus only on OO code like c++ does, we C devs sit here amused since we stuck to functional based programming, we want objects, we use struct, we want initialisers, we define them separate from the object, we want long lived buffers & object, we use malloc/realloc or some other common allocation function, yes we have to jump through a few more hoops and be more careful with our pointers but we can do pretty much whatever we want with the data we have, c++ on the other simply shot itself in the foot, chest, hands and is now pointing the gun at it's own head :)

[@broken_abi6973]

C++ does not only focus on OO like you claim. It has always been a multi paradigm language. C is not functional based programming either. There are many issues with the "solutions" you proposed, which by the way, are also available to C++ devs.

[@loremipsum3147]

Lol c has nothing to do with functional languages

[@testbin-i4x]

It's actually hard for me to understand this talk. :(

[@ABaumstumpf]

The operators "^" and ":" is the Worst idea in C++ by a long shot. The earlier proposal of "refl_expr" was not very nice but was way better of conveying the meaning. Currently it looks like reflections will be about as useful as std::regex - aka absolutely broken and useless. C++ really is going the way that Stroustroup often said he wanted to avoid - some fools in the ivory tower deciding how it should be, making it just more bloated, complex and useless.