←back to thread

196 points svlasov | 1 comments | | HN request time: 0.21s | source
Show context
lallysingh ◴[] No.40851756[source]
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.

replies(2): >>40851990 #>>40855315 #
stiglitz ◴[] No.40851990[source]
By ”stagnation” do you mean “not getting new features”?
replies(3): >>40852374 #>>40852457 #>>40852476 #
jacoblambda ◴[] No.40852476[source]
C++ has gotten a ton of quality of life features with each update. The issue is less that new features aren't coming and more that new features bake through countless iterations of proposals for close to or often over a decade until everyone in WG21 is happy.

So it's not that we aren't getting features. They are coming quite fast and people regularly complain that new C++ has too many things for them to learn and keep up with. The issue is that those are the same features everyone has been asking for for over a decade so the people that really care found workarounds and eventually move over to the new std way of doing things when they can while everyone else continues waiting for that one feature they really care about.

replies(7): >>40853490 #>>40854139 #>>40854365 #>>40854369 #>>40854878 #>>40855193 #>>40856663 #
account42 ◴[] No.40855193[source]
Personally I'd rather the comitte take longer and require more implementation experience before accepting new features. There are still too many half-baked ideas that turn out to be mistakes afterwards, resulting in either needless breaking changes or being stuck with bad solutions.

This is especially true for library features where users can always use third party libraries for containers/algorithms that are yet to be standardized (or indifinitely - not everything should be added to the stdlib). But even language features can and should exist as compiler extensions before we are stuck with them.

replies(2): >>40855217 #>>40855232 #
1. gpderetta ◴[] No.40855232[source]
Failed library features at least can be relatively easily deprecated, forgotten and left to rot on the side. Language features will bloat the language almost forever.

One nice advantage of static reflection, macros and other form of program synthesis is that you can experiment with new syntax as a library before committing to integrating it to the base language.