Qualifying std::move, std::forward, etc. is unnecessary #431
Comments
|
In the LWG at Lenexa, there was widespread agreement that we should keep saying |
|
As far as #285 concerned, the core language has a different policy: It uses std::something to highlight that, in fact, the function defined in the standard library is meant, not some random user function that happens to have that name. Note that the general provision you cited is in the library front matter and therefore not supposed to apply to the core language section. |
|
Stephan: What about examples of user-written code, e.g. in 30.6.8p8? Those examples are (obviously) not written inside "namespace std", so they become ill-formed when we drop the "std::". |
|
Hmm. I agree that the Core clauses shouldn't be touched. I'd also be fine with not touching user examples like 30.6.8/8, although I consider that to be debatable - note that the example is obviously a snippet omitting |
The standard library specifies that references to its names are assumed to be prefixed by '::std::'. Therefore, we can remove any explicit 'std::' prefixes. [iterator.range] was not touched, because it is unclear whether argument-dependent lookup was intended to be disabled here. Fixes cplusplus#431.
The standard library specifies that references to its names are assumed to be prefixed by '::std::'. Therefore, we can remove any explicit 'std::' prefixes. [iterator.range] was not touched, because it is unclear whether argument-dependent lookup was intended to be disabled here. Fixes cplusplus#431.
The standard library specifies that references to its names are assumed to be prefixed by '::std::'. Therefore, we can remove any explicit 'std::' prefixes. [iterator.range] was not touched, because it is unclear whether argument-dependent lookup was intended to be disabled here. Fixes cplusplus#431.
The standard library specifies that references to its names are assumed to be prefixed by '::std::'. Therefore, we can remove any explicit 'std::' prefixes. [iterator.range] was not touched, because it is unclear whether argument-dependent lookup was intended to be disabled here. Fixes cplusplus#431.
The standard library specifies that references to its names are assumed to be prefixed by '::std::'. Therefore, we can remove any explicit 'std::' prefixes. [iterator.range] was not touched, because it is unclear whether argument-dependent lookup was intended to be disabled here. Fixes #431.
Library Standardese almost universally qualifies
std::moveandstd::forward. It occasionally qualifies other things, likestd::pair,std::is_constructible, etc. (especially in TR1-era stuff). All of this is unnecessary, due to 17.6.1.1 [contents]/3:"Whenever a name
xdefined in the standard library is mentioned, the namexis assumed to be fully qualified as::std::x, unless explicitly described otherwise. For example, if the Effects section for library functionFis described as calling library functionG, the function::std::Gis meant."Observe how /3 correctly uses
::std::(which is what implementers have to do, for functions where ADL is a concern) while the rest of the Library casually saysstd::which isn't even correct. And the occurrences ofstd::do not correspond to where implementers must defend against ADL - e.g.pairis never vulnerable (it's a class template, so implementers can say it unqualified), butequal()is, yet the Library qualifiesstd::pairbut saysequal()unqualified. Madness!To avoid useless verbosity, I recommend relying on /3 to the greatest extent possible. The Library should eliminate all occurrences of
std::unless something is especially ambiguous to humans (in which case we should consider formally saying::std::). Currently, I believe the only human-ambiguous cases are those where ADL is involved elsewhere - for example, because we rely on ADL swap in some places, it is good and desirable to say::std::swapwhen we mean that.This means that I disagree with #285, at least when it comes to saying
std::raise. (A citation link wheneverraiseis mentioned would be entirely fine, though.)The text was updated successfully, but these errors were encountered: