Description
[contents]
Whenever a name
x
defined in the standard library is mentioned, the namex
is assumed to be fully qualified as::std::x
, unless explicitly described otherwise.
At the point of [allocator.uses.construction]/1, the name make_obj_using_allocator
is not yet "defined". However, as the "described below" wording in the paragraph, it seems that this should be equivalent to the definition corresponding to the declaration above [allocator.uses.construction]/16. So, does it mean make_obj_using_allocator
should be considered qualified with ::std::
?
Another problem is the Effects in [allocator.uses.construction]/16. The expression make_from_tuple<T>(uses_allocator_construction_args<T>(alloc, std::forward<Args>(args)...))
have both qualified and unqualified names. Does it mean that make_from_tuple
and uses_allocator_construction_args
are unqualified, or both of them are qualified with ::std::
?
There is also an issue seems not quite editorial to me: is there any reason to make uses_allocator_construction_args
above unqualified? It actually can cause ambiguity with simulation code of uses_allocator_construction_args
implementation out of the namespace std
. I have not found any clue in P0591R4.
(Note that libstdc++ qualifies make_from_tuple
but no uses_allocator_construction_args
in the implementation of make_obj_using_allocator
. On the other hand, libc++ misses both.)
Activity
FrankHB commentedon Jul 31, 2019
If "unqualified names don't perform ADL" is the right decision, both implementations are not conforming, and the
std::
beforeforward
is redundant.jwakely commentedon Jul 31, 2019
Yes. Because [contents] says so, and nothing says to discount [contents] here.
Both are assumed to be fully qualified. Our editorial policy is to consistently qualify
std::move
andstd::forward
. That doesn't mean [contents] doesn't apply.It's assumed to be qualified, so the question is irrelevant.
That's simply a bug in libstdc++ (which has now been fixed).
I don't see any issue with the C++ draft here.
FrankHB commentedon Aug 1, 2019
I'm a bit confused. Is this policy implied in the draft? I find [allocator.requirements]/2 to omit the qualification, but no more general rules. (BTW, there are some redundant
std::
in the Table 34 under this rule, and Table 33 seems actually irrelevant.)Good. Hope it clearer after #1913 is applied.
Great, though now I have to fight with not only
__cplusplus
, but also far more trickier__GLIBCXX__
or something else.jensmaurer commentedon Oct 3, 2019
The text before those tables reads "Within Tables 33 and 34, the use of move and forward always refers to std::move and std::forward, respectively." That seems to be pretty clear.