6 ms·

And in the wild (supported by all major compilers) we will see this somewhere around 2040…

• nly 1y ago
  Not if you run RHEL: dnf install gcc-toolset-X
  • pjmlp 1y ago
    GCC only started supporting C++20 modules in a usable form, last month, and there are still parts missing from C++20. So expect at very least 2026 + 5 => 2031 for that command to provide a complete C++26 development experience.
    • gpderetta 1y ago
      Sure but this is about constexpr, not modules.
      • mkoubaa 1y ago
        Modules implicate the entire toolchain, backward compatibility, and binary compatibility. constexpr is a compiler feature. Wild that they are being compared.
        • pjmlp 1y ago
          See how many years it takes for a compiler on average to be 100% compliant after a standard is ratified, not widely at all when one wants to write portable code, regardless.
          • int_19h 1y ago
            In practice it's the same thing with C++ today as it is with web standards: you have to evaluate support on a feature-by-feature basis, and stick to the features that are supported on all the implementations you care about. And constexpr in stdlib is much more likely to get quick adoption across all implementations than something like modules.
            • pjmlp 1y ago
              Not really, folks have done a good job turning the Web into ChromeOS, there is only one relevant browser still standing.
              • int_19h 1y ago
                Safari/WebKit is still very relevant, and it's quite different from Blink even if they have shared origins.
              • mkoubaa 1y ago
                I'll buy this when people who write web pages for a living exclusively support Chrome
      • pjmlp 1y ago
        Indeed, however there is a certain velocity how many years after the standard gets ratified until the compilers get fully compliant.
    • ender341341 1y ago
      The compiler writers have had a ton of issues implementing modules and aren't particularly excited for them (the committee seems to have forgot the lessens learned from c++98 and not having full implementations for crazy hard things) on the other hand constexpr changes tend to be picked up pretty quickly, and a lot of them tend to be things that the compiler/stl authors themselves are asking for.
      • pjmlp 1y ago
        Since C++14 that I have increasingly changed my mind that it should only be about existing practice, and no paper should be accepted without implementation, regardless of how basic it may be, just like in other language ecosystems. Yes it might prevent lots of cool features, yet how good are they if it takes years to be implemented across compilers, or they turn out to be yet another export template. Additionally it would help to reduce count from those 300+ people, not everyone is there for good reasons, some only want to have a "contributed to C++" on their background, and then they are gone.
        • ender341341 1y ago
          > should only be about existing practice, and no paper should be accepted without implementation When c++11 was still c++0x they made a big song and dance about how they wouldn't do another export template boondoggle and wanted an implementation available for any features. Then they seemed to have completely forget about it when doing modules (which not that surprisingly is running into similar issues that export templates did).
    • deleted 1y ago
      [deleted]
    • WalterBright 1y ago
      C++ should have just copied D modules (and the modules that ImportC supports).
      • phire 1y ago
        Yeah, maybe they should have, would have been a lot simpler. But C++ really wanted modules to be a more or less drop in replacement for #include (or at least a set of common use cases), which really pushed up the required level of complexity.
        • pjmlp 1y ago
          That it was already there via Apple and Google's work, header maps, but what we got was Microsoft proposal, after some collaboration with Google. Note at WWDC 2024, the module improvements regarding build times, in what concerns C++, it is based on header maps as well. Apple is not even bothering with C++20 modules.
      • pjmlp 1y ago
        Maybe, however always telling what they should have done won't change the languages position on the market, so we get what we can have. Many things D might have done it first, yet it is hardly acknowledged, or has any impact on adoption without a major backer. I also keep telling WG14 should care about security, since Usenet days, fighting windmills.
        • WalterBright 1y ago
          Many features of D have since found their way into C++, such as ranges, compile time function execution, thousands separators in numeric literals, conditional compilation blocks, etc.
          • pjmlp 1y ago
            Indeed, and with them, the reasons for the industry to care about what D offers sadly diminishes. Also some of those features predate D, having shown first in Ada, Common Lisp, Eiffel, as discussed in the past.
• ratmeadow 1y ago
  And bug free, 2060. (Back in C++20 days I had a terrible habit of finding bugs in MSVC's implementations of metaprogramming features, after they claimed to be feature complete on C++20. Probably because people use these features less. Even now I occasionally receive emails about those bugs they've finally fixed.)