First job I had out of college was in C++ using CFront 1.3.

I'd really like to be able to use modules before I retire.

Modules seem to be sidestepped. I wonder why is that, they would make the languages so much easier to work with. One reason is that they might involve a big overhaul of toolchains, I think...

Er, they submitted the TS to ISO for inclusion in the standard ("The Modules TS is sent out for its comment and approval (PDTS) ballot."). That's the final step from the committee for including it in C++20.

Not quite.

It was submitted for PDTS (proposed draft technical standard), which means it goes out for balloting to ISO national bodies. That balloting either succeeds (at which point you have a Techincal Specification) or it comes back to the committee with comments that the committee then has to respond to (and then another round of balloting happens). Once it's accepted as a Technical Specification, it's still not part of the C++ International Standard. That's a decision the committee comes to at their own pace, much like what happened at this meeting where the Concepts TS was accepted (as amended) into the IS.

Think of a TS somewhat like a beta. There's no assurance that the contents of the TS will go into the IS at all or in the exact form it was originally specified in, but that's certainly the hope when the TS is published.

IMO, it's more important what's happening on the ground, that is, in the compilers, than the "official" status in the standardization pipeline. After all, we've had export in the standard and we all know where it went (in case you don't: nobody implemented it).

And on the ground things are looking pretty good: the big three (GCC, Clang, and VC) have modules supported to various degrees and are actively working on improving things.

Not sidestepped, but they're a TS that may (should, I think?) be folded in C++20 once there's a consensus.

There are a couple nice implementations already, so I'd expect no problem with a modules proposal making the cut for the next standard.

They did, and they shipped it in VS2017.

One reason is that Google and other members that agree with their position, want to be able to export macros from modules, instead of using the multiple file approach, meaning #include for macros and modules for everything else.

A simple solution is already possible with Microsoft's implementation, but they don't like it, it seems.

    #ifndef LEGACY_HEADER
    #define LEGACY_HEADER

    #include "legacy_header_macros.h"

    import new_header_module;

    #endif

Right now there isn't much public information how they will sort this out.

So, we're going to get compile time reflection?

This is the proposal:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p019...

Nor is it the place for commenting on being downvoted.

C++ is still used widely, in many domains, and there's a lot of code out there that can benefit from incremental improvements to the language and the STL. As for who the standards are targeted to: Microsoft, Apple, Google, Adobe, Yahoo!, major financial institutions, game developers large and small alike, etc., etc. Microsoft claims that 1.5 million C++ devs use Visual Studio, so that's probably where the low estimate for the number of active/semi-active C++ developers would be.

Quite a large number of people use C++.

C++ is 3rd place on the latest (July 2017) TIOBE index, behind Java and C.

C++ sits in a niche wherein its competitors have mostly died out with the notable exception of D and few modern languages threaten to replace it other than Rust. It's a low-level language that provides expressitivity that's a step above C but fits in a similar role in environments that are unable to use garbage collection or as the base on which larger systems are built.

After all, you need your fancy virtual machines and modern runtimes to be written in something and there are few choices other than C/C++.