Skip to content

[allocator.uses.construction] Problems about the unqualified names #3111

Closed
@FrankHB

Description

@FrankHB
Contributor

[contents]

Whenever a name x defined in the standard library is mentioned, the name x 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

FrankHB commented on Jul 31, 2019

@FrankHB
ContributorAuthor

If "unqualified names don't perform ADL" is the right decision, both implementations are not conforming, and the std:: before forward is redundant.

jwakely

jwakely commented on Jul 31, 2019

@jwakely
Member

So, does it mean make_obj_using_allocator should be considered qualified with ::std::?

Yes. Because [contents] says so, and nothing says to discount [contents] here.

Does it mean that make_from_tuple and uses_allocator_construction_args are unqualified, or both of them are qualified with ::std::?

Both are assumed to be fully qualified. Our editorial policy is to consistently qualify std::move and std::forward. That doesn't mean [contents] doesn't apply.

is there any reason to make uses_allocator_construction_args above unqualified?

It's assumed to be qualified, so the question is irrelevant.

(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++ qualifies both.)

That's simply a bug in libstdc++ (which has now been fixed).

I don't see any issue with the C++ draft here.

FrankHB

FrankHB commented on Aug 1, 2019

@FrankHB
ContributorAuthor

Our editorial policy is to consistently qualify std::move and std::forward.

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.)

That doesn't mean [contents] doesn't apply.

Good. Hope it clearer after #1913 is applied.

That's simply a bug in libstdc++ (which has now been fixed).

Great, though now I have to fight with not only __cplusplus, but also far more trickier __GLIBCXX__ or something else.

jensmaurer

jensmaurer commented on Oct 3, 2019

@jensmaurer
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @jwakely@FrankHB@jensmaurer

        Issue actions

          [allocator.uses.construction] Problems about the unqualified names · Issue #3111 · cplusplus/draft