On Mon, 9 Mar 2020 at 11:38, Bryce Adelstein Lelbach aka wash
<brycelelbach_at_[hidden]> wrote:
>
> 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?

Here's an attempt to provide some suggestions as to "why?":
Can we
- improve the API of the standard library; make it easier to use, by
for example fixing the problem you mention
in your latter email, 'why is tuple in <tuple> but pair in <utility>',
so in general, making it less of a hassle
to figure out what to include/import?
- reap any other benefits from better modularity? For this I have no
clear answer at this time.
  * can we get better encapsulation of implementation details?
  * can that lead to improved build times over importable headers?
  * can that lead to better tooling integration?

Based on P0581, a reorganization certainly seems to be in the cards.

> 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?

There are ongoing efforts to improve freestanding, and some parts of
that effort are not entirely coupled with a modular
standard library or any other reorg; some parts are just about
conditionally providing some functionality (and conditionally
_not_ providing it), and some parts are about reorganizing the content
insofar as what standard library facilities are
part of freestanding. So, I would guess it's certainly in scope, but
whether it should all be in this particular scope
is not so obvious.