Assorted wording issues with P0433R2

[timsong-cpp]

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]

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

[jwakely]

How about:

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

?

[jwakely]

And maybe follow it by:

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

[timsong-cpp]

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

[zygoloid]

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.