Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Assorted wording issues with P0433R2 #1524

Closed
timsong-cpp opened this issue Mar 7, 2017 · 5 comments
Closed

Assorted wording issues with P0433R2 #1524

timsong-cpp opened this issue Mar 7, 2017 · 5 comments
Assignees
@jwakely
Milestone
C++17 DIS

Comments

@timsong-cpp
Copy link
Contributor

timsong-cpp commented Mar 7, 2017 •
edited

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?
@jwakely jwakely self-assigned this Mar 7, 2017
@jwakely
Copy link
Member

jwakely commented Mar 7, 2017

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

@jwakely jwakely added this to the C++17 milestone Mar 7, 2017
@jwakely
Copy link
Member

jwakely commented Mar 16, 2017

How about:

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

?

@jwakely
Copy link
Member

jwakely commented Mar 16, 2017

And maybe follow it by:

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

@timsong-cpp
Copy link
Contributor Author

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

@jwakely jwakely mentioned this issue Mar 16, 2017
Closed
@zygoloid
Copy link
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
Assignees

@jwakely jwakely

Labels
None yet
Projects
None yet
Milestone
C++17 DIS
Development

No branches or pull requests
3 participants
@zygoloid @jwakely @timsong-cpp