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@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@lists.isocpp.org>
Cc: Bryce Adelstein Lelbach aka wash <brycelelbach@gmail.com>; Ben Boeckel via Modules <modules@lists.isocpp.org>; C++ Library Evolution Working Group <lib-ext@lists.isocpp.org>; ISO C++ Tooling Study Group <sg15@lists.isocpp.org>; Nathan Sidwell <nathan@acm.org>
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?