Alternative suggestion for future namespace extension; i.e., std2

152 views
Skip to first unread message

smellyw...@gmail.com

unread,
Jun 25, 2016, 11:56:48 AM6/25/16
to ISO C++ Standard - Discussion
std[0-9], i.e., std2

I can imagine many reasons to want to create distinct sets of namespaces to help preserve backwards compatibility with existing code. However, adding numbers to names for reboots has never seemed very clean.

I have always used namespaces in C++ to avoid collisions and use the best names possible rather than resorting to duplicating the class or function name with an appended number.

The name of the library is the C++ Standard Library; here are a few alternative suggestions, which exclude some popular suggestions that I have already read about (cpp, cxx, stl):

  • cstd::
  • csl::
  • stdl::

Has the alternative been considered to place extensions in a sub-namespace of std:: related to the version of the standard?
  • std::cpp::
  • std::cpp11::
  • std::cpp14::
  • std::cpp17::
The two suggestions above become even more compelling if you combine them together, and leave the new base namespace empty:
  • cstd::cpp::
  • cstd::cpp11::
  • cstd::cpp14::
  • cstd::cpp17::
  • cstd::cpp17::experimental
Then there are a few options to hoist the default library into the base namespace:

  // 1. Compiler flag could set the default within cstd.

  // 2. Alternatively
  namespace cstd
  {
    using namespace cstd::cpp17;
  }

  cstd::vector<int> v;
 

  // 3. Or a user-defined namespace alias
  namespace cpp = cstd::cpp17;
 
  cpp::vector<int> v;

   

Best Regards,
Paul

Nicol Bolas

unread,
Jun 25, 2016, 12:19:34 PM6/25/16
to ISO C++ Standard - Discussion, smellyw...@gmail.com
On Saturday, June 25, 2016 at 11:56:48 AM UTC-4, smellyw...@gmail.com wrote:
std[0-9], i.e., std2

I can imagine many reasons to want to create distinct sets of namespaces to help preserve backwards compatibility with existing code. However, adding numbers to names for reboots has never seemed very clean.

I have always used namespaces in C++ to avoid collisions and use the best names possible rather than resorting to duplicating the class or function name with an appended number.

So why is `cstd` better than `std`? Indeed, I find it to be worse, as it suggests that it refers to the C standard rather than the C++ standard.

The point of having a new namespace is to be able to have a fresh start with names. You don't have to keep dodging around the fact that `std::sort` exists with a particular signature. If you want a new sort function that has a new signature to match a new paradigm (range-based rather than interator based), then putting it in a new namespace is essential.

But what goes into `std2` will still be a large collection of things, not a single, specific library. Containers, IO, networking, etc will all be part of the same collection. So there is no more meaning to `std2` than there was to `std`. The only meaning is that it is "the C++ standard library, version 2".

The name of the library is the C++ Standard Library; here are a few alternative suggestions, which exclude some popular suggestions that I have already read about (cpp, cxx, stl):

  • cstd::
  • csl::
  • stdl::

Has the alternative been considered to place extensions in a sub-namespace of std:: related to the version of the standard?
  • 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.

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.

Andrey Semashev

unread,
Jun 25, 2016, 4:11:53 PM6/25/16
to std-dis...@isocpp.org, smellyw...@gmail.com
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?

Tony V E

unread,
Jun 25, 2016, 4:31:17 PM6/25/16
to std-discussion
On Sat, Jun 25, 2016 at 4:11 PM, Andrey Semashev <andrey....@gmail.com> wrote:
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.

It is expected that you will use both std and std2 at the same time.  New ranges with old vector, etc.
 

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?


std::cpp2014::string and 2017::string would interoperate via string_view.

But it is not like there would be a 2014 string, a 2017 string, a 2020 string,... 
We don't want new revisions of classes with each release.
But every 25 years? maybe.

Tony
 
--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussio...@isocpp.org.
To post to this group, send email to std-dis...@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-discussion/.

Andrey Semashev

unread,
Jun 26, 2016, 4:41:24 AM6/26/16
to std-dis...@isocpp.org
On Sunday, 26 June 2016 11:37:24 MSK Tony V E wrote:
> On Sat, Jun 25, 2016 at 4:11 PM, Andrey Semashev <andrey....@gmail.com>
> wrote:
> >
> > 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?
>
> std::cpp2014::string and 2017::string would interoperate via string_view.

Which string_view - std::cpp2014::string_view or std::cpp2017::string_view? :)
And what about other classes, like vector or list or optional?

inkwizyt...@gmail.com

unread,
Jun 26, 2016, 6:35:46 AM6/26/16
to ISO C++ Standard - Discussion

It could be same type. Some basic class can be shared between versions.
This would allow creating interfaces that will work with every version of std lib.
Even better if they could be ABI compatible between standard releases.

Nicol Bolas

unread,
Jun 26, 2016, 8:58:03 AM6/26/16
to ISO C++ Standard - Discussion, inkwizyt...@gmail.com

It would still violate strict aliasing to pass a `cpp2014::string_view` to a function that takes a `const cpp2017::string_view&` without a conversion, whether it's in your translation unit or not. Not unless they are aliases to the same type. So there would have to be a conversion. For `string_view` a conversion is pretty light. But not so much for `vector` or `string`.

And if they're aliases for the same type... what's the point of giving them different typenames and putting them in different namespaces at all?

To me, the whole point of reserving the new namespaces is so that a clean, non-backwards compatible break can be made. So that the committee can make significant breaking changes for new APIs (ranges), while still offering the old behavior in `std`.

So it's well understood by all that if there is a `std2::vector`, that type is not the same as `std::vector`. There may be some interoperability features, but they are distinct types with distinct implementations and distinct behaviors.

ezmag...@gmail.com

unread,
Jun 27, 2016, 9:43:33 AM6/27/16
to ISO C++ Standard - Discussion
Hello!

There's been some(1) support(2) over on the Reddit thread for using `iso` as an alternative, although there's also some counterarguments.

I wanted to put it out here for discussion, and because I personally like `iso`. :)

inkwizyt...@gmail.com

unread,
Jun 27, 2016, 12:05:30 PM6/27/16
to ISO C++ Standard - Discussion, inkwizyt...@gmail.com

I thought about alias of same type. They could be defined in `std::common` or something, and shared by all std namespaces.
Idea behind that classes would be easing connecting code from different versions of std or even C. Great example of this is `string_view`.

Andrey Semashev

unread,
Jun 27, 2016, 1:06:46 PM6/27/16
to std-dis...@isocpp.org
On 06/27/16 16:43, ezmag...@gmail.com wrote:
> Hello!
>
> There's been some
> <https://www.reddit.com/r/cpp/comments/4pmlpz/what_the_iso_c_committee_added_to_the_c17_working/d4mf9k7?context=10000>(1)
> support
> <https://www.reddit.com/r/cpp/comments/4py6sl/hypothetically_which_standard_library_warts_would/d4p8emu?context=10000>(2) over
> on the Reddit thread for using `iso` as an alternative, although there's
> also some counterarguments
> <https://www.reddit.com/r/cpp/comments/4pmlpz/what_the_iso_c_committee_added_to_the_c17_working/d4mvgr8?context=10000>.
>
> I wanted to put it out here for discussion, and because I personally
> like `iso`. :)

I agree with the referenced argument. The iso name just sounds like an
endorsement of a single standardisation organization, and C++ should
stay neutral, IMO.

Nicol Bolas

unread,
Jun 27, 2016, 1:37:26 PM6/27/16
to ISO C++ Standard - Discussion, inkwizyt...@gmail.com

Then what's the point of them being in different namespaces at all? If the standard requires that std::cpp17::string_view and std::cpp14::string_view are the same type, then why are there two of them?

The whole point of having a new namespace is to be able to do things that you cannot do in the old namespace. To introduce definitions that would conflict in a non-BC way with the old namespace. To introduce new classes/functions that have different, non-BC behavior from the old ones.

That's why there version specific namespaces make no sense. They don't solve the actual problem, and they create new burden on the standard and the implementations to retain old versions of types.

Nevin Liber

unread,
Jun 27, 2016, 1:46:20 PM6/27/16
to std-dis...@isocpp.org
On 27 June 2016 at 12:37, Nicol Bolas <jmck...@gmail.com> wrote:
That's why there version specific namespaces make no sense. They don't solve the actual problem, and they create new burden on the standard and the implementations to retain old versions of types.

And users as well.

For instance, if you want to take a string_view as a parameter, do you have to write overloads to take all string_views?  Ugh.  Been there (for code that might use both boost::string_ref and std::experimental::string_view).

Separate namespaces assume the only problem is compatibility.  IMO, it isn't, nor is it even the most important one, and the unintended consequences caused by different types, especially different vocabulary types, are worse.
--
 Nevin ":-)" Liber  <mailto:ne...@eviloverlord.com>  +1-847-691-1404
Reply all
Reply to author
Forward
0 new messages