On 3/3/23 12:30, Sebastian Wittmeier via Std-Proposals wrote:
> Hi Andrey,
>
> you may have good reasons for not yet supporting/using some new features
> like modules in your C++ development environment yet.
>
> And this well explains your stance in regards to using enumerate in this
> case.
>
> However, for specifying C++26 and beyond modules should IMHO be
> considered as the default, when talking about small improvements (saving
> a few characters to define/increment a loop variable), especially if a
> compatible header solution exists at the same time.

Standard library module is not available in the currently released (and
AFAIK next to be released) versions of gcc, which means it probably
won't be released this year. The compiler version with the module
support needs to ship in a mainstream Linux OS like Debian or RHEL to
become relevant, and users, including me should shift from OS versions
that use older compilers that don't have modules (because conditionally
using modules is not worth it), so at the very least 5 years, most
likely more.

But most importantly, if modules have a problem with both importing and
including the same stuff (which will happen if you use libraries that
have not switched to modules), if modules have a problem with macros, or
if `import std` is more expensive than `#include <cstddef>` (or pick any
other lightweight header) then modules are DOA and I'm not seeing myself
using them ever.

So yeah, modules are a hard sell for me. And I imagine I'm not the only
one, and even for people more enthusiastic to use modules, they simply
won't be able to in the forseeable future due to the first paragraph.
Given this, I think, it is irresponsible to consider standard library
extensions disregarding the cost of using those features through
`#incldue` mechanism. Because I'm pretty sure `#includes` will stay
relevant at least for a decade ahead, possibly more.