On 3/3/23 12:58, Jonathan Wakely wrote:
>
>
> On Fri, 3 Mar 2023 at 09:53, Andrey Semashev via Std-Proposals
> <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]>>
> wrote:
>
> 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.
>
>
> Why do you think a new loop variable language feature added to C++26
> would be available any sooner?

I'm not advocating for adding this as a core language feature. In fact,
I argued against it in a prior post.

> 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),
>
> Not necessarily.

That doesn't sound confident. I repeat, there must be *zero* problems
mixing modules and `#includes`, because I guarantee that's what's going
to happen during the lengthy transition period. If that transition is
not possible then modules are DOA.

> 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.
>
> "if `import std` is more expensive than `#include <cstddef>`" is absurd,

No, it's not. In a given header/TU, do you use `import` or `#include`?
For a header, are you going to penalize its users by using `import`?
Answers on these questions depend on whether one is cheaper than the
other for a given set of used std features (or, put simply, the
`#includes` there currently are). And `import` needs to be better in the
majority of cases, down to single simple includes like `cstddef` and
`utility`.

> most programs use a lot more from the standard library than that. If you
> don't want to include more than that, that's fine. But you don't get to
> argue against new library features on the basis that you've made
> personal choices that most people would consider a silly self-imposed
> limitation.

I'm arguing that disregarding the cost of `#including` the feature is
irresponsible. Saying "oh, we have modules now, #includes don't matter"
is irresponsible and not a valid argument when discussing a new library
feature.