Here and above, there's no need to say "for all N" nor "for all T", because we're already within the context of inplace_vector, i.e., the injected-class-name of some particular specialization of inplace_vector, with a particular T and N.

Note to anyone who cares: This used to say something to the effect of "no non-static member functions of", but LWG discussion in St Louis seems to have come down on the side of "who cares if e.g. capacity is constexpr-friendly, when size itself isn't," and so "no member functions [period]" is indeed what was polled and approved.

I guess it's more appropriate to say

no member functions of inplace_vector are guaranteed to be usable in constant expressions

or

it is unspecified whether any member function of inplace_vector is usable in constant expressions

But this seemingly needs an LWG issue, and the sentence will be dropped if P3074 lands.

By my recollection, LEWG explicitly discussed the fact that library vendors have the freedom to add noexcept but not to add constexpr, and we were explciitly deciding to forbid library vendors from making any of these functions constexpr-friendly in those cases.

That was certainly given as a rationale for why iterator is unconditionally constexpr-friendly: at least some of us were under the impression that if we had said "Under such-and-such conditions iterator does not meet the constexpr iterator requirements," then we would be forcing library vendors to invent an iterator type that was "basically T* but constexpr-unfriendly," just for that purpose.

However, if (my recollection of) our impression was wrong — if library vendors actually do have the freedom to make inplace_vector "more constexpr than strictly necessary" — well, IMHO that wouldn't be a bad outcome at all. :)

I've left this as is - this wording (e.g. the use of inplace_vector<T, N>) is used throughout this section; to change it only here would be inconsistent, while changing it elsewhere requires additional wording.

Here and above, there's no need to say "for all N" nor "for all T",

But it doesn't say for all N, it says for N > 0.

This is being moot as the restriction itself is being removed by P3074.

"The move assignment operator," said Ford Prefect quietly, "is also an assignment operator."

If this is trying to hint that we might use an assignment operator other than the move-assignment operator (e.g. if the only operator= available is void operator=(std::any), like this) — well, that's true, but I still think there's no sense in mentioning a subset of assignment operators (the move assignment operators) here.

Cf. the Complexity element, which gets it right, in my book.

this is a normative change, please forward to LWG.

It should either be "the copy assignment operator or move assignment operator" or "an assignment operator", but the approved wording and the suggested change are both bad.

See also #3208. It was very unfortunate that the bad wording got copied.

I think "the copy assignment operator or move assignment operator" is still defective, because T can be copy/move-assigned by an assignment operator which is a template when the real copy/move assignment operator is not selected.

@jwakely Could we turn this, and #3208, into an LWG issue?

https://cplusplus.github.io/LWG/issue4123

Thanks!