If “fixing” freestanding helps in anyway, then shouldn’t it be in scope?

 

-- Gaby

 

From: Ext <ext-bounces@lists.isocpp.org> On Behalf Of Bryce Adelstein Lelbach aka wash via Ext
Sent: Monday, March 9, 2020 2:38 AM
To: Ville Voutilainen <ville.voutilainen@gmail.com>
Cc: Bryce Adelstein Lelbach aka wash <brycelelbach@gmail.com>; Ben Boeckel via Modules <modules@lists.isocpp.org>; ISO C++ Tooling Study Group <sg15@lists.isocpp.org>; C++ Library Evolution Working Group <lib-ext@lists.isocpp.org>; Evolution Working Group mailing list <ext@lists.isocpp.org>; Nagy-Egri Máté Ferenc <nagy-egri.mate@wigner.mta.hu>
Subject: Re: [isocpp-ext] [SG15] Modularization of the standard library andABI stability

 

The first sentence rom P0581:

 

> With recent progress made on the ‘module’ language feature, it is long overdue that we start a  conversation around uses of modules in the standard library.

My question is, simply, "why?"

 

Let's quantify what we hope to achieve and what the scope of the work is, as I tried to do two posts ago.

 

Is this a reorganization or not?

 

If yes, is redefining the freestanding library in scope?

 

If it is a reorganization and redefining the freestanding library isn't in scope, does that mean we don't want to "fix" freestanding?

 

On Mon, Mar 9, 2020, 02:32 Bryce Adelstein Lelbach aka wash <brycelelbach@gmail.com> wrote:

I wrote a paper that in large part was a response to P0581, so yes, I've read it a few times.

 

https://wg21.link/P1453

 

It sounded like you were trying to make a point. Can you be clearer about what that point was?

 

On Mon, Mar 9, 2020, 02:25 Ville Voutilainen <ville.voutilainen@gmail.com> wrote:

On Mon, 9 Mar 2020 at 11:16, Bryce Adelstein Lelbach aka wash via Ext
<ext@lists.isocpp.org> wrote:
>
> > From a users perspective, having STL modules would speed up compilation times immensely
>
> As I said in my email, standard library headers are already importable in C++20. So your implementation can already replace #include <vector> with import <vector>;
>
> I don't know that we can really do that much more than that; we could have an import std.vector, but it sounds like (0) std::vector would have to remain in the global module and (1) standard library implementation details would probably have to remain in the global module as well.
>
> TL;DR the use case you described is already covered in C++20.

I wonder whether the people commenting on this thread have read
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0581r1.pdf.