On the freestanding front, I am currently of the opinion that no special considerations should be made for freestanding during modularization. While I wish that it could be as easy as `import std.freestanding`, I don’t think we can get away with that while getting a large freestanding library.

Here are specific, difficult cases:

  1. std::string_view. It would be really nice to have this in freestanding, but it throws std::out_of_range. Std::out_of_range has a constructor that takes a const std::string &. Std::string is poorly suited to freestanding. It would be challenging to organize standard library modules in such a way that freestanding has no hosted dependencies, yet also includes std::string_view.
  2. Constexpr vector. I have future dreams of allowing vector to be used at compile time on freestanding, but not requiring it to be usable at runtime.

With those difficult cases in mind, I believe that the modules should not be organized according to freestanding or not. A freestanding implementation’s modules should just have different contents than a hosted implementation.

From: SG15 <sg15-bounces_at_[hidden]> On Behalf Of Tjernstrom, Staffan via SG15
Sent: Monday, March 9, 2020 7:33 AM
To: sg15_at_lists.isocpp.org; Evolution Working Group mailing list <ext_at_[hidden]>
Cc: Tjernstrom, Staffan <Staffan.Tjernstrom_at_[hidden]>; Ben Boeckel via Modules <modules_at_[hidden]>; C++ Library Evolution Working Group <lib-ext_at_[hidden]>; Nathan Sidwell <nathan_at_[hidden]>
Subject: [EXTERNAL] Re: [SG15] [isocpp-ext] Modularization of the standard library andABI stability

Somewhat backward looking, but a flavour of real-world user experience.

When implementing new libraries on the Microsoft toolchain, we've noticed that the current implementation of the STL module(s) as provided do not match our general compilation environment. In particular, the floating point mode mode differs between the two. That's probably an indication of the sort of issues that make this tricky.

But it does mean that for at least sorting purposes in that toolchain:

import std.vector;

does not equate to

#include <vector>

From: SG15 [mailto:sg15-bounces_at_lists.isocpp.org] On Behalf Of Bryce Adelstein Lelbach aka wash via SG15
Sent: Monday, 09 March, 2020 07:26
To: Evolution Working Group mailing list <ext_at_[hidden]<mailto:ext_at_[hidden]>>
Cc: Bryce Adelstein Lelbach aka wash <brycelelbach_at_[hidden]<mailto:brycelelbach_at_[hidden]>>; Ben Boeckel via Modules <modules_at_[hidden]<mailto:modules_at_[hidden]>>; C++ Library Evolution Working Group <lib-ext_at_[hidden]<mailto:lib-ext_at_[hidden]>>; ISO C++ Tooling Study Group <sg15_at_[hidden]<mailto:sg15_at_[hidden]>>; Nathan Sidwell <nathan_at_[hidden]<mailto:nathan_at_[hidden]>>
Subject: Re: [SG15] [isocpp-ext] Modularization of the standard library andABI stability

If I understand correctly, you are suggesting that the reorganized modularized standard library could be ABI incompatible with the standard library you get with #includes.

I have noticed an interesting property of all the "compromise" proposals for ABI evolution; they are all the moral equivalent of std2. I'm not making any judgements on whether that is good or bad.

While I think your idea has merit, I think we should probably make it a design goal that:

import std.vector

and

#include <vector>

give you the same std::vector.

Does anyone disagree with that goal?


________________________________

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.