[namespace.std] Reopening a namespace within `std`

[frederick-vs-ja]

Is the following example well-defined?

#include <ranges>

class MyClass;

namespace std::ranges {
  template<>
  inline constexpr bool disable_sized_range<MyClass> = true;
}

It seemingly violates [namespace.std]/1 by defining the ranges namespace in std. I guess an LWG issue would be needed if we want to allow it.

If we want to keep it disallowed, perhaps it would be helpful to add an example with correction.

E.g.

#include <ranges>

class MyClass;

namespace std::ranges { // undefined behavior (or ill-formed, no diagnostic required): defining a namespace in std
  template<>
  inline constexpr bool disable_sized_range<MyClass> = true;
}

template<>
inline constexpr bool std::ranges::disable_sized_range<MyClass> = true; // OK

[eisenwave]

I think we obviously want namespace std::ranges { to be valid to spell, but the wording doesn't support that. A definition of a namespace like that is a declaration by definition, so that seems in violation of https://eel.is/c++draft/namespace.std#1

The reason I'm saying we obviously want it is that people have been writing struct hash specializations inside of a namespace std block for a long time, and it would be very surprising if this was permitted for namespace std, but not for namespace std::ranges.

However, it's also not obvious how to solve this. We don't want to allow:

namespace std {
namespace fun {
}
}

... because this interferes with future standardization. Only namespaces that already exist should be spellable.

However, this then poses the question whether the following is valid:

// no includes

namespace std::ranges {
}

Is the user allowed to define std::ranges without any prior declaration?

It seems like there are some non-editorial problems that need to be addressed here.

[jwakely]

Is the user allowed to define std::ranges without any prior declaration?

That would be adding a declaration to std which isn't allowed. Is there a reason to do that though? You can't define a specialization of a template in std::ranges without including the relevant header to see the primary template. Is there anything that is both useful and valid that requires being able to define std::ranges this way?

[eisenwave]

Is there a reason to do that though?

I would mainly find it surprising because it makes the order of declarations in the program matter. It could mean:

namespace std::ranges { } // IFNDR
#include <ranges>

#include <ranges>
namespace std::ranges { } // OK

That is despite the fact that both forms are (to my knowledge) semantically equivalent. We'd be policing code style.

[jwakely]

But there's no reason to allow it.

If the implementation defines:

namespace std { inline namespace __version_9000 { namespace ranges {

then you break it by declaring std::ranges yourself. If you include a library header which declares std::ranges as a qualified name that refers to std::__version_9000::ranges then it works.

This is not code style. This is "you do not get to declare things in namespace std", because it might conflict with what is actually supposed to be in std.

[jwakely]

I think we obviously want namespace std::ranges { to be valid to spell, but the wording doesn't support that. A definition of a namespace like that is a declaration by definition, so that seems in violation of https://eel.is/c++draft/namespace.std#1

The wording says you can't add declarations or definitions to std. Re-declaring std::ranges is not adding anything, it's a declaration referring to something that was already added to std.

Only namespaces that already exist should be spellable.

That's exactly what "adds" is saying.

Maybe better words can be used, but I'm not seeing an actual defect here.

[eisenwave]

I'm happy with a better phrasing than "add" and treating this as editorial, if your opinion as LWG chair is that there's no normative defect.

[jwakely]

[namespace.def.general] distinguishes between extending an existing namespace and introducing a namespace-name.

If "adds" isn't clear enough for referring to namespaces, maybe we could extend that sentence in [namespace.std] p1 to make an exception for extending a namespace under std.

[eisenwave]

It may be worth pointing out that if we permit re-declarations of standard library entities in general though, then the following is presumably well-defined:

#include <cmath>
namespace std {
double sqrt(double);
}

Just like namespace std::ranges, this is not "adding" anything, just re-declaring something that already exists. However, I don't think we want these re-declarations of functions to be allowed.

If "adds" isn't clear enough for referring to namespaces, maybe we could extend that sentence in [namespace.std] p1 to make an exception for extending a namespace under std.

Sounds like a safe option.

[jensmaurer]

From a core language perspective, I think

namespace std {         // #1, declaration
  namespace ranges {}   // #2, declaration
}

(Even a benign redeclaration is still a fresh "declaration" in the core language sense.) So, I think #2 "adds a declaration", even though the semantic effect of that declaration is to extend a namespace. (The latter doesn't mean it's not a separate declaration. Both apples and pears are fruit.)

A limited editorial fix for [namespace.std] p1 is welcome as a pull request.