7 ms·

It's the other way around. You are the real programmer and the committee and the "modern C++" crowd are more interested playing with legos instead of shipping a

It's the other way around. You are the real programmer and the committee and the "modern C++" crowd are more interested playing with legos instead of shipping actual software. No way anything std::meta gets into serious production; too flexible in some ways, too inflexible in others, too much unpredictability, too high impact on compilation times - just like always with newer additions to the C++ standard. It takes one look at coding standards of real-world projects to see how irrelevant this stuff is. And like always, the problem std::meta is purported to solve has been solved for years.

d_tr 1y ago
What's the solution that's been around for years? > ... just like always with newer additions to the C++ standard. This is objectively laughable.
- jcranmer 1y ago
  > What's the solution that's been around for years? Build tools to generate C++ code from some other tool. Interface description languages, for example, or something like (going back decades here) lex and yacc even.
  - d_tr 1y ago
    Great. But you can do anything you want by generating code. Why not have a standard solution instead of everyone doing their own, possibly buggy thing complicating their build process even more?
    - tw061023 1y ago
      Reframe it as "you can do precisely what you need by generating code" and there is your answer. Which is far better than to rely on a party which, as I said, has precisely nothing to do with what anyone needs. Which will inevitably produce solutions that can only partially (I am being generous here) be used in any particular situation. As for "possibly buggy" - look, I can whip up a solid *DL parser complete with a C++ code generator in what, a week? And then polish it from that. The committee will work for several years, settle on a barely working design, then it will take some years to land in major compilers, then it will turn out it is unusable because someone forgot a key API or it was unfeasible on VAX or something like that. And my build process is not complicated, and never will be. It can always accomodate another step. Mainly because I don't use CMake.
      - birn559 1y ago
        My perception is that C++XY features are wildly used in general. Of course there are some nobody uses, but that's not generally true. So your basic assumption is wrong. We are at C++20 and I wouldn't like to work for a company that uses an earlier standard.
        tw061023 1y ago
        Well, either you carefully vet which C++ features you use and my assumption still stands, or you don't - in which case I would rather not like to work in your company.
      - comex 1y ago
        You can write a parser for an IDL, but you can’t reasonably write a parser for C++. So you have to move the definition of whatever types of methods or fields you want to reflect on into the IDL, instead of defining them natively in C++. (Or worse, have separate definitions in both the IDL and C++.) Which tends to be cumbersome – especially if you want to define a lot of generic types (since then the code generator can’t statically determine the full list of types). It can work, but there’s a reason I rarely see anyone using this approach.
        tw061023 1y ago
        Why would I want to write a C++ parser? IDL/DDL is the source of truth, moving the type definitions there is the whole point. There is only one definition for each type, which is in the *DL, corresponding C++ headers are generated and everything is statically known.
  - a_t48 1y ago
    I've been down this road. I ended up with a config YAML (basically - an IDL) that goes into a pile of jinja files and C++ templates - and it always ended up better and easier to read to minimize the amount of jinja (broken syntax highlighting, the fact that you are writing meta meta code, it's a hot mess). I'd much prefer to generate some bare structs with some minimal additional inline metadata than to generate both those structs and an entire separate set of structs describing the first ones. std::meta lets me do the former, the latter is what's possible right now.
  - eschneider 1y ago
    Debugging/modifying code generated from someone's undocumented c++ code generator is pretty close to the top of my list of unpleasant things to do. Yes, you can eventually figure out what to do by looking at the generated code and taking apart the code generator and figuring out how it all works but I'll take built-in language features any day.
- mpyne 1y ago
  I was literally running into something a couple of days ago on my toy C++ project where basic compile-time reflection would have been nice to have for some sanity checking. And even if it's true that some things can be done already with specific compilers and implementation-specific hacks, it would be really nice to be able to do those things more straightforwardly. My experience with C++ changes has been that the recent additions to compile-time metaprogramming operations is that they improve compile times rather than make it worse, because you don't have to do things like std::enable_if<> hacks and recursive templates to do things that a simple generic lambda or constexpr conditional will do, which are more difficult for both you and the compiler.
  - corysama 1y ago
    The history of C++ has been one long loop of: 1. So many necessary common practices of C++ are far too complicated! 2. Std committee adds features to make those practices simpler. 3. C++ keeps adding features. It’s too big. They should cut out the old stuff! 4. The std committee points at the decade-long Python 3 fiasco. 5. Repeat.
    - birn559 1y ago
      Do they point at python 3? They were committed to backward compatibility long before python3 happened. To me it feels like they have fleshed out key paradigms so that is not a mess anymore. They are not there yet with compile time evaluation (constexpr consteval,...), at least with C++20, not sure if it's mostly finished with C++23/26. The language itself and std is quite bloated but writing modern C++ isn't that complicated anymore in my experience.
    - zozbot234 1y ago
      It's pure Stockholm syndome. There's even a nice C++ committee paper that summarizes this as "Remember the Vasa!" https://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p0977r0.pdf https://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p0977r0...
  - spacechild1 1y ago
    Constexpr if and fold expressions have been a god send!
- tw061023 1y ago
  Whip up some kind of in-house IDL/DDL parser, codegen from that. Which, precisely, additions do not fit my points?
  - jandrewrogers 1y ago
    Completely inadequate for many use cases. IDL/DDL is one of the least interesting things you could do with reflection in C++. You can already do a lot of that kind of thing with existing metaprogramming facilities.
    - tw061023 1y ago
      Which use cases? What exactly you can do with "existing metaprogramming facilities"?
  - birn559 1y ago
    Most of the time, I will prefer standard C++ over a full hand made layer of complexity that needs maintenance.
- DLoupe 1y ago
  For example, boost library's "describe" and similar macro based solutions. Been using this for many years.
funkychicken 1y ago
I know the trading firm I work at will be making heavy use of reflection the second it lands… we had a literal party when it made it into the standard.
- mylons 1y ago
  sure, but instagram was created by a handful of people with python and got a billion dollar exit in 2012.
  - birn559 1y ago
    What has that to do with the topic? Warren Buffet made billions without any do knowledge about programming or deeper knowledge about computers.
    - mikrl 1y ago
      Mansa Musa was so rich he decreased the local gold to silver exchange rate in Egypt by 12% without ANY modern technology! https://en.wikipedia.org/wiki/Mansa_Musa#Wealth https://en.wikipedia.org/wiki/Mansa_Musa#Wealth
  - emmelaich 1y ago
    And Youtube used Python almost exclusively at the start AFAIK. Then again Scott Meyers said he's never written a C++ program professionally.
    - motorest 1y ago
      > Then again Scott Meyers said he's never written a C++ program professionally. I think you're inadvertently misrepresenting Scott Meyers' claim. Cited from somewhere else: > I'll begin with what many of you will find an unredeemably damning confession: I have not written production software in over 20 years, and I have never written production software in C++. Nope, not ever. He went on to clarify that he made a living out of consultancy, not writing software. He famously retired from C++ in 2015, too.
deleted 1y ago
[deleted]
jandrewrogers 1y ago
The stream of modern C++ features have been a god-send for anyone that cares about high-performance, high-reliability software. Maybe that doesn’t apply to your use case but C++ is widely used in critical data infrastructure. For anyone that does care about things like performance and reliability, the changes to modern C++ have largely been obvious and immediately useful improvements. Almost all C++ projects I know in the high-performance data infrastructure space live as close to the bleeding edge of new C++ features as the compiler implementations make feasible. And no, reflection hasn’t “been solved for years” unless you have a very misleading definition of “solved”. A lot of the C++ code I work with is heavily codegen-ed via metaprogramming. Despite the relative expressiveness and flexibility of C++ metaprogramming, proper reflection will dramatically improve what is practical in a strict and type-safe way at compile-time.
- tw061023 1y ago
  [flagged]
  - William_BB 1y ago
    You sound like you subscribe to "Orthodox C++". Speaking seriously, I agree there's definitely a lot of bloat in the new C++ standards. E.g. I'm not a fan of the C++26 linalg stuff. But most performance-focused trading firms still use the latest standard with the latest compiler. Just a small example of new C++ features that are used every day in those firms: Smart pointers (C++11), Constexpr and consteval (all improvements since C++11), Concepts (C++20), Spans (C++20), Optional (C++17), String views (C++17)
    - motorest 1y ago
      > I'm not a fan of the C++26 linalg stuff. I don't agree at all. For most, linear algebra is the primary reason they pick up C++. Up until now, the best option C++ newbies had was to go through arcane processes to onboard a high performance BLAS implementation which then requires even more arcane steps such as tuning. With C++26, anyone can simply jump into implementing algorithms. If anything, BLAS support was conspicuously missing from C++ (and also C). This blend of comments is more perplexing given that a frequent criticism of C++ is its spartan standard lib, and how the selling point of some commercial software projects such as Matlab is that, unlike C++, linear algebra work is trivial.
throwaway9832 1y ago
Every problem is solved. We should stop making anything. Specially CRUD apps, because how is that even programming? What does it solve that hasn't been solved? This line of thinking is not productive. It is a mistake to see yourself as what you do, because then you're cornering yourself into defending it, no matter what.
pjmlp 1y ago
I bet CERN might eventually replace their Python based code generators with C++26 reflection.
- tw061023 1y ago
  Which problem would this solve for them?
  - pjmlp 1y ago
    Two language problem, kind of well known issue in engineering tradeoffs.
    - Culonavirus 1y ago
      As an example, most of the big js/ts ecosystem expansion to the server (RSC/Next/RR7/Expo/...) over the last few years is driven by the wish to have everything under one roof and one language. People just don't want to maintain two completely different stacks (one on the server, one on the client).
  - dguest 1y ago
    It would standardize something they've done in an ad-hoc way for decades. They have a library called "reflex" [1] which adds some reflection, and which was (re)written by cannibalizing a lot of llvm code. They actually use the reflection to serialize a lot of the LHC data. It's kind of neat that it works. It's also a bit fidgety: the cannibalized code can cause issues (which, e.g. prevented C++11 adoption for a while in some experiments), and now CERN depends on bits of an old C++ compiler to read their data. Some may question the wisdom of making a multi-billion dollar dataset without a spec and dependent on internals of C++ classes (indeed experiments are slowly moving to formats with a clear spec), but for sure having a standard for reflection is better than the home-grown solution they rely on now. [1]: https://indico.cern.ch/event/408139/contributions/979831/attachments/815762/1117785/185_Reflex_Roiser_paper.pdf https://indico.cern.ch/event/408139/contributions/979831/att...
    - 1y ago
otabdeveloper4 1y ago
Yeah, wait till you find out what's behind the curtain in your web engine and AI. Hint: it's C++, and yes, it will eventually use stuff like std::meta heavily.
- tw061023 1y ago
  If you would check my comments, you would see I am quite aware. And no, it will not, just like it was with streams, ranges and whatever else.
zozbot234 1y ago
> No way anything std::meta gets into serious production Rust proc macros get used in serious production, even though they're quite slow to compile. Sure, std::meta is probably a bit clunkier, but that's expected from new C++ features as you say.
- Thom2000 1y ago
  Sadly, Rust proc macros operate on tokens and any serious macro implementation needs third-party crates. Compile-time reflection, with good, built in API, akin to C# Roslyn would be a real boon.
  - galangalalgol 1y ago
    Any serious anything needs third party crates. Coming from c++ this has been the most uncomfortable aspect of rust to me, but I am acclimating.
a_t48 1y ago
Prediction: it will be used heavily for things like command line arg parsing, configuration files, deserialization, reflection into other languages. It will probably be somewhat a pain to use, but better than the current alternative mashup of macros/codegen/template metaprogramming that we have now for some of these solutions. It will likely mostly be used for library code, where someone defines some nice utilities for you, that do something useful, so that you don't have to worry about it. I don't think for the most part it has to hurt compile times - it might even be faster than the current mess, as well - less use of templates. I don't think the "legos" vs "shipping" debate here is really valid. One can write any type of code in any language. I'm a freak about C++, but if someone wants to ship in Python or JS, the more power to them - one can write code that's fast enough to not matter, but takes advantage of those languages' special features.
germandiago 1y ago
I embrace Modern C++, but slower than the committee, when the big three have the feature. I really think reflection + annotations will give us the chance to have much better serialization and probably something more similar to Python decorators. That will be plenty useful and it is going to transform a part of C++ ecosystem, for example I am thinking of editors that need to reflect on data structures or web frameworks such as Crow or Drogon, Database access libraries...
adev_ 1y ago
> And like always, the problem std::meta is purported to solve has been solved for years. It is rare to read something more moronic than that The Rust equivalent of std::meta (procedural macros) are heavily used everywhere including in serialization framework, debugging and tracers. And that's not surprising at all: Compile time introspection is much more powerful and lightweight than codegen for exactly the same usage.
- dwroberts 1y ago
  > It is rare to read something more moronic than that It's not actually wrong though is it - real codebases have been implementing reflection and introspection through macro magic etc. for decades at this point. I guess it's cool they want to fix it in the language, but as always, the approach is to make the language even more complex than it already is - e.g. two new operators (!) in the linked article
  - adev_ 1y ago
    > been implementing reflection and introspection through macro magic etc. for decades at this point. Having a flaky pile of junk as an alternative is never been an excuse to not fix the problem properly. Every proper modern language (Rust, Kotlin, Zig, Swift, even freaking Golang) has a form of runtime reflection or static introspection. Only C++ does not. It was done historically with a mess of macros or a pre-compiler (qt-moc) that all have an entire pile of issue. > the approach is to make the language even more complex than it already is - e.g. two new operators The problem of rampant complexity in C++ is not so much about the new features when they bring something and make sense. It is about its inability to remove the old stuff even if it is consensual that it is garbage (e.g iostreams).
    - d_tr 1y ago
      > Having a flaky pile of junk as an alternative is never been an excuse to not fix the problem properly. Thank you. Some people use the phrases "real projects" and "production code" as if they imply some standard of high quality.
motorest 1y ago
> It's the other way around. You are the real programmer and the committee and the "modern C++" crowd are more interested playing with legos instead of shipping actual software. I think this is the most clueless comment I ever read in HN. I hope the site is not being hit with it's blend of September. I was going to explain to you how fundamentally wrong your comment was, but it's better to just kindly ask you to post in Reddit instead.
nickysielicki 1y ago
> the problem std::meta is purported to solve has been solved for years. What solution is that? A Python script that spits out C++ code?

d_tr 1y ago

What's the solution that's been around for years? > ... just like always with newer additions to the C++ standard. This is objectively laughable.

jcranmer 1y ago
> What's the solution that's been around for years? Build tools to generate C++ code from some other tool. Interface description languages, for example, or something like (going back decades here) lex and yacc even.
- d_tr 1y ago
  Great. But you can do anything you want by generating code. Why not have a standard solution instead of everyone doing their own, possibly buggy thing complicating their build process even more?
  - tw061023 1y ago
    Reframe it as "you can do precisely what you need by generating code" and there is your answer. Which is far better than to rely on a party which, as I said, has precisely nothing to do with what anyone needs. Which will inevitably produce solutions that can only partially (I am being generous here) be used in any particular situation. As for "possibly buggy" - look, I can whip up a solid *DL parser complete with a C++ code generator in what, a week? And then polish it from that. The committee will work for several years, settle on a barely working design, then it will take some years to land in major compilers, then it will turn out it is unusable because someone forgot a key API or it was unfeasible on VAX or something like that. And my build process is not complicated, and never will be. It can always accomodate another step. Mainly because I don't use CMake.
    - birn559 1y ago
      My perception is that C++XY features are wildly used in general. Of course there are some nobody uses, but that's not generally true. So your basic assumption is wrong. We are at C++20 and I wouldn't like to work for a company that uses an earlier standard.
      - tw061023 1y ago
        Well, either you carefully vet which C++ features you use and my assumption still stands, or you don't - in which case I would rather not like to work in your company.
    - comex 1y ago
      You can write a parser for an IDL, but you can’t reasonably write a parser for C++. So you have to move the definition of whatever types of methods or fields you want to reflect on into the IDL, instead of defining them natively in C++. (Or worse, have separate definitions in both the IDL and C++.) Which tends to be cumbersome – especially if you want to define a lot of generic types (since then the code generator can’t statically determine the full list of types). It can work, but there’s a reason I rarely see anyone using this approach.
      - tw061023 1y ago
        Why would I want to write a C++ parser? IDL/DDL is the source of truth, moving the type definitions there is the whole point. There is only one definition for each type, which is in the *DL, corresponding C++ headers are generated and everything is statically known.
- a_t48 1y ago
  I've been down this road. I ended up with a config YAML (basically - an IDL) that goes into a pile of jinja files and C++ templates - and it always ended up better and easier to read to minimize the amount of jinja (broken syntax highlighting, the fact that you are writing meta meta code, it's a hot mess). I'd much prefer to generate some bare structs with some minimal additional inline metadata than to generate both those structs and an entire separate set of structs describing the first ones. std::meta lets me do the former, the latter is what's possible right now.
- eschneider 1y ago
  Debugging/modifying code generated from someone's undocumented c++ code generator is pretty close to the top of my list of unpleasant things to do. Yes, you can eventually figure out what to do by looking at the generated code and taking apart the code generator and figuring out how it all works but I'll take built-in language features any day.
mpyne 1y ago
I was literally running into something a couple of days ago on my toy C++ project where basic compile-time reflection would have been nice to have for some sanity checking. And even if it's true that some things can be done already with specific compilers and implementation-specific hacks, it would be really nice to be able to do those things more straightforwardly. My experience with C++ changes has been that the recent additions to compile-time metaprogramming operations is that they improve compile times rather than make it worse, because you don't have to do things like std::enable_if<> hacks and recursive templates to do things that a simple generic lambda or constexpr conditional will do, which are more difficult for both you and the compiler.
- corysama 1y ago
  The history of C++ has been one long loop of: 1. So many necessary common practices of C++ are far too complicated! 2. Std committee adds features to make those practices simpler. 3. C++ keeps adding features. It’s too big. They should cut out the old stuff! 4. The std committee points at the decade-long Python 3 fiasco. 5. Repeat.
  - birn559 1y ago
    Do they point at python 3? They were committed to backward compatibility long before python3 happened. To me it feels like they have fleshed out key paradigms so that is not a mess anymore. They are not there yet with compile time evaluation (constexpr consteval,...), at least with C++20, not sure if it's mostly finished with C++23/26. The language itself and std is quite bloated but writing modern C++ isn't that complicated anymore in my experience.
  - zozbot234 1y ago
    It's pure Stockholm syndome. There's even a nice C++ committee paper that summarizes this as "Remember the Vasa!" https://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p0977r0.pdf https://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p0977r0...
- spacechild1 1y ago
  Constexpr if and fold expressions have been a god send!
tw061023 1y ago
Whip up some kind of in-house IDL/DDL parser, codegen from that. Which, precisely, additions do not fit my points?
- jandrewrogers 1y ago
  Completely inadequate for many use cases. IDL/DDL is one of the least interesting things you could do with reflection in C++. You can already do a lot of that kind of thing with existing metaprogramming facilities.
  - tw061023 1y ago
    Which use cases? What exactly you can do with "existing metaprogramming facilities"?
- birn559 1y ago
  Most of the time, I will prefer standard C++ over a full hand made layer of complexity that needs maintenance.
DLoupe 1y ago
For example, boost library's "describe" and similar macro based solutions. Been using this for many years.

funkychicken 1y ago

I know the trading firm I work at will be making heavy use of reflection the second it lands… we had a literal party when it made it into the standard.

mylons 1y ago
sure, but instagram was created by a handful of people with python and got a billion dollar exit in 2012.
- birn559 1y ago
  What has that to do with the topic? Warren Buffet made billions without any do knowledge about programming or deeper knowledge about computers.
  - mikrl 1y ago
    Mansa Musa was so rich he decreased the local gold to silver exchange rate in Egypt by 12% without ANY modern technology! https://en.wikipedia.org/wiki/Mansa_Musa#Wealth https://en.wikipedia.org/wiki/Mansa_Musa#Wealth
- emmelaich 1y ago
  And Youtube used Python almost exclusively at the start AFAIK. Then again Scott Meyers said he's never written a C++ program professionally.
  - motorest 1y ago
    > Then again Scott Meyers said he's never written a C++ program professionally. I think you're inadvertently misrepresenting Scott Meyers' claim. Cited from somewhere else: > I'll begin with what many of you will find an unredeemably damning confession: I have not written production software in over 20 years, and I have never written production software in C++. Nope, not ever. He went on to clarify that he made a living out of consultancy, not writing software. He famously retired from C++ in 2015, too.

deleted 1y ago

[deleted]

jandrewrogers 1y ago

The stream of modern C++ features have been a god-send for anyone that cares about high-performance, high-reliability software. Maybe that doesn’t apply to your use case but C++ is widely used in critical data infrastructure. For anyone that does care about things like performance and reliability, the changes to modern C++ have largely been obvious and immediately useful improvements. Almost all C++ projects I know in the high-performance data infrastructure space live as close to the bleeding edge of new C++ features as the compiler implementations make feasible. And no, reflection hasn’t “been solved for years” unless you have a very misleading definition of “solved”. A lot of the C++ code I work with is heavily codegen-ed via metaprogramming. Despite the relative expressiveness and flexibility of C++ metaprogramming, proper reflection will dramatically improve what is practical in a strict and type-safe way at compile-time.

tw061023 1y ago
[flagged]
- William_BB 1y ago
  You sound like you subscribe to "Orthodox C++". Speaking seriously, I agree there's definitely a lot of bloat in the new C++ standards. E.g. I'm not a fan of the C++26 linalg stuff. But most performance-focused trading firms still use the latest standard with the latest compiler. Just a small example of new C++ features that are used every day in those firms: Smart pointers (C++11), Constexpr and consteval (all improvements since C++11), Concepts (C++20), Spans (C++20), Optional (C++17), String views (C++17)
  - motorest 1y ago
    > I'm not a fan of the C++26 linalg stuff. I don't agree at all. For most, linear algebra is the primary reason they pick up C++. Up until now, the best option C++ newbies had was to go through arcane processes to onboard a high performance BLAS implementation which then requires even more arcane steps such as tuning. With C++26, anyone can simply jump into implementing algorithms. If anything, BLAS support was conspicuously missing from C++ (and also C). This blend of comments is more perplexing given that a frequent criticism of C++ is its spartan standard lib, and how the selling point of some commercial software projects such as Matlab is that, unlike C++, linear algebra work is trivial.

throwaway9832 1y ago

Every problem is solved. We should stop making anything. Specially CRUD apps, because how is that even programming? What does it solve that hasn't been solved? This line of thinking is not productive. It is a mistake to see yourself as what you do, because then you're cornering yourself into defending it, no matter what.

pjmlp 1y ago

I bet CERN might eventually replace their Python based code generators with C++26 reflection.

tw061023 1y ago
Which problem would this solve for them?
- pjmlp 1y ago
  Two language problem, kind of well known issue in engineering tradeoffs.
  - Culonavirus 1y ago
    As an example, most of the big js/ts ecosystem expansion to the server (RSC/Next/RR7/Expo/...) over the last few years is driven by the wish to have everything under one roof and one language. People just don't want to maintain two completely different stacks (one on the server, one on the client).
- dguest 1y ago
  It would standardize something they've done in an ad-hoc way for decades. They have a library called "reflex" [1] which adds some reflection, and which was (re)written by cannibalizing a lot of llvm code. They actually use the reflection to serialize a lot of the LHC data. It's kind of neat that it works. It's also a bit fidgety: the cannibalized code can cause issues (which, e.g. prevented C++11 adoption for a while in some experiments), and now CERN depends on bits of an old C++ compiler to read their data. Some may question the wisdom of making a multi-billion dollar dataset without a spec and dependent on internals of C++ classes (indeed experiments are slowly moving to formats with a clear spec), but for sure having a standard for reflection is better than the home-grown solution they rely on now. [1]: https://indico.cern.ch/event/408139/contributions/979831/attachments/815762/1117785/185_Reflex_Roiser_paper.pdf https://indico.cern.ch/event/408139/contributions/979831/att...
  - 1y ago

otabdeveloper4 1y ago

Yeah, wait till you find out what's behind the curtain in your web engine and AI. Hint: it's C++, and yes, it will eventually use stuff like std::meta heavily.

tw061023 1y ago
If you would check my comments, you would see I am quite aware. And no, it will not, just like it was with streams, ranges and whatever else.

zozbot234 1y ago

> No way anything std::meta gets into serious production Rust proc macros get used in serious production, even though they're quite slow to compile. Sure, std::meta is probably a bit clunkier, but that's expected from new C++ features as you say.

Thom2000 1y ago
Sadly, Rust proc macros operate on tokens and any serious macro implementation needs third-party crates. Compile-time reflection, with good, built in API, akin to C# Roslyn would be a real boon.
- galangalalgol 1y ago
  Any serious anything needs third party crates. Coming from c++ this has been the most uncomfortable aspect of rust to me, but I am acclimating.

a_t48 1y ago

Prediction: it will be used heavily for things like command line arg parsing, configuration files, deserialization, reflection into other languages. It will probably be somewhat a pain to use, but better than the current alternative mashup of macros/codegen/template metaprogramming that we have now for some of these solutions. It will likely mostly be used for library code, where someone defines some nice utilities for you, that do something useful, so that you don't have to worry about it. I don't think for the most part it has to hurt compile times - it might even be faster than the current mess, as well - less use of templates. I don't think the "legos" vs "shipping" debate here is really valid. One can write any type of code in any language. I'm a freak about C++, but if someone wants to ship in Python or JS, the more power to them - one can write code that's fast enough to not matter, but takes advantage of those languages' special features.

germandiago 1y ago

I embrace Modern C++, but slower than the committee, when the big three have the feature. I really think reflection + annotations will give us the chance to have much better serialization and probably something more similar to Python decorators. That will be plenty useful and it is going to transform a part of C++ ecosystem, for example I am thinking of editors that need to reflect on data structures or web frameworks such as Crow or Drogon, Database access libraries...

adev_ 1y ago

> And like always, the problem std::meta is purported to solve has been solved for years. It is rare to read something more moronic than that The Rust equivalent of std::meta (procedural macros) are heavily used everywhere including in serialization framework, debugging and tracers. And that's not surprising at all: Compile time introspection is much more powerful and lightweight than codegen for exactly the same usage.

dwroberts 1y ago
> It is rare to read something more moronic than that It's not actually wrong though is it - real codebases have been implementing reflection and introspection through macro magic etc. for decades at this point. I guess it's cool they want to fix it in the language, but as always, the approach is to make the language even more complex than it already is - e.g. two new operators (!) in the linked article
- adev_ 1y ago
  > been implementing reflection and introspection through macro magic etc. for decades at this point. Having a flaky pile of junk as an alternative is never been an excuse to not fix the problem properly. Every proper modern language (Rust, Kotlin, Zig, Swift, even freaking Golang) has a form of runtime reflection or static introspection. Only C++ does not. It was done historically with a mess of macros or a pre-compiler (qt-moc) that all have an entire pile of issue. > the approach is to make the language even more complex than it already is - e.g. two new operators The problem of rampant complexity in C++ is not so much about the new features when they bring something and make sense. It is about its inability to remove the old stuff even if it is consensual that it is garbage (e.g iostreams).
  - d_tr 1y ago
    > Having a flaky pile of junk as an alternative is never been an excuse to not fix the problem properly. Thank you. Some people use the phrases "real projects" and "production code" as if they imply some standard of high quality.

motorest 1y ago

> It's the other way around. You are the real programmer and the committee and the "modern C++" crowd are more interested playing with legos instead of shipping actual software. I think this is the most clueless comment I ever read in HN. I hope the site is not being hit with it's blend of September. I was going to explain to you how fundamentally wrong your comment was, but it's better to just kindly ask you to post in Reddit instead.

nickysielicki 1y ago

> the problem std::meta is purported to solve has been solved for years. What solution is that? A Python script that spits out C++ code?