Skip to content

Assorted wording issues with P0433R2  #1524

Closed
@timsong-cpp

Description

@timsong-cpp
Contributor

In f913f21#diff-0fb8725b6f959c00f8cef02d54e8c125R1021 (currently in the motions-2017-03-lwg-19 branch) we have:

Likewise, the extent to which an implementation determines that a type cannot be
an allocator is unspecified, except that as a minimum a type \tcode{A} not satisfying
both of the following conditions shall not qualify as an allocator:

  • [condition 1]
  • [condition 2]

It's not clear whether a type that satisfies only one of the two conditions is guaranteed to fail to qualify as an allocator or not. Perhaps the sentence can be editorially reworded to make the intent clearer?

@jwakely also pointed out that the paper pervasively uses wording of the form "if it has an X template parameter that is called with a type that meows", which is problematic because a) deduction guides are not "called", and b) "that is called ..." is actually modifying "template parameter", which also can't be "called".

Finally, the input iterator and allocator weasel-wording are placed in [sequence.reqmts] but now are used for all containers, not just sequence containers. Perhaps they should be moved to a better place?

Activity

self-assigned this
on Mar 7, 2017
jwakely

jwakely commented on Mar 7, 2017

@jwakely
Member

Thanks for creating the issue. I'll deal with this after the branch is merged to master.

added this to the C++17 milestone on Mar 7, 2017
jwakely

jwakely commented on Mar 16, 2017

@jwakely
Member

How about:

as a minimum a type \tcode{A} shall not qualify as an allocator unless it satisfies both of the following conditions:

?

jwakely

jwakely commented on Mar 16, 2017

@jwakely
Member

And maybe follow it by:

[Note: Implementations may impose additional conditions which must be satisfied to qualify as an allocator. -- end note]

timsong-cpp

timsong-cpp commented on Mar 16, 2017

@timsong-cpp
ContributorAuthor

Yes, that is much clearer. The note SGTM too (but probably can also mention input iterator).

zygoloid

zygoloid commented on Mar 20, 2017

@zygoloid
Member

I've merged all of the above changes other than the new note. I don't see the need for a note given that we already normatively say "the extent to which an implementation determines that a type cannot be
an allocator is unspecified", and I don't like the wording of the note in question because it suggests that the implementation can impose unbounded additional constraints, including things not related to the allocator requirements. It's certainly not OK for an implementation to say that a type must have a foobar member to qualify as an allocator.

If the "the extent to which [...]" wording is not sufficiently clear, I'd prefer that we get a handle on what's unclear about it and fix that rather than paraphrasing the rule in a note.

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

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Relationships

None yet

    Development

    No branches or pull requests

      Participants

      @zygoloid@jwakely@timsong-cpp

      Issue actions

        Assorted wording issues with P0433R2 · Issue #1524 · cplusplus/draft