On Sat, Jun 25, 2016 at 7:19 PM, Nicol Bolas <
jmck...@gmail.com> wrote:
> On Saturday, June 25, 2016 at 11:56:48 AM UTC-4,
smellyw...@gmail.com wrote:
>>
>> std::cpp::
>> std::cpp11::
>> std::cpp14::
>> std::cpp17::
>
>
> The longer the chain of namespaces, the greater the likelihood of someone
> doing this:
>
> using namespace std::cpp17;
>
> And we absolutely do not want to encourage that. People do it with the 5
> character `std::` often enough as it is. Let's not give them even more
> reason to do so.
They will have no less reason to do so with std2 or any other
namespace. I guess std:: could point to a "default" library
implementation selected by compiler switches, and std::cppX could be
used to qualify the version when needed.
In any case, I we do have to have a namespace designating the standard
library version, make it a descriptive one. And the last two digits of
the year is not descriptive enough (i.e. cpp17 can be 2017, 2117 and
so on).
> Furthermore, having version-specific namespaces makes implementations (and
> specifications) needlessly complicated. The C++17 spec has to define how
> `vector` behaves in both C++14 and C++17. Implementations now have to
> maintain two separate version of `vector` if it changed. And so forth.
>
> If compilers want to have some version switch, that's fine. But it shouldn't
> be required by the standard, nor should the version be baked into the C++
> code using it.
Agreed. I can add that versioning will also introduce a lot of
interoperability issues. Imagine a library that uses
std::cpp2014::string and another library that uses
std::cpp2017::string. Are these libraries able to interoperate? If
yes, how does the standard library scale as more and more versions
appear?