Issues about P3086R5

[mingxwa]

Ported from: microsoft/proxy#358

@frederick-vs-ja opened on Oct 20, 2025:

I wanted to open a PR for these but it seems that the proposal isn't open-sourced.

I've found some issues in the latest proposal for now (P3086R5).

1. The term "trivial type" is deprecated by P3247R2. Instead of saying "X is a trivial type", perhaps we should say "is_trivially_copyable_v<X> and is_trivially_default_constructible_v<X> are both true".
2. The "Constraints" element ([structure.specifications]/3.1) is not used.
3. The "Require" element has been removed from [structure.specifications]. Given its only usage specifies conditions entirely detectible at compile time, it should be replaced with "Mandates".
4. Given constraint_level is a scoped enumeration type, its underlying type is fixed and implicit specified as int per the current wording, and hence a value larger than constraint_level::trivial or less than constraint_level::none (e.g. constraint_level(127) or constraint_level(-1) respectively) can be valid. Perhaps we don't want to accidently make such a value have valid effect.

---

E.g. I think it's clearer to specify the copy and move constructors as following.

proxy(const proxy& rhs) noexcept(F::copyability == constraint_level::trivial || F::copyability == constraint_level::nothrow);

-?-. Effects: If rhs contains a value of type P, direct-non-list-initializes the contained value of the constructed object with a const P lvalue that refers to rhs’s contained value. Otherwise, constructs an empty proxy.

-?-. Remarks: This constructor is trivial if F::copyability == constraint_level::trivial is true, and deleted if F::copyability == constraint_level::trivial, F::copyability == constraint_level::nothrow, F::copyability == constraint_level::nontrivial are all false.

[Drafting note: It is redundant to say a trivial copy constructor performs a bitwise copy.]

proxy(proxy&& rhs) noexcept(F::relocatability == constraint_level::nothrow);

-?-. Constraints: Either F::relocatability == constraint_level::nontrivial or F::copyability == constraint_level::nothrow is true.

-?-. Effects: If rhs contains a value of type P, moves its contained value into the constructed object (using either a move construction of P or an implementation-defined trivial relocation when permitted by the constraint levels). Otherwise, constructs an empty proxy.

-?-. Postconditions: rhs does not contain a value.

@mingxwa on Oct 21, 2025:

Hi @frederick-vs-ja,

Thank you for reviewing P3086R5 and for providing concrete wording suggestions. Although the paper draft repository is not public, I will cite your feedback in the revision log of the next submission.

Points 1-3

Acknowledged. I will integrate those wording adjustments in the next revision.

Point 4 (enum class constraint_level)

Rather than altering the enumeration, I plan to strengthen the facade-related requirements: each of F::copyability, F::relocatability, and F::destructibility must be exactly one of the four enumerators; otherwise facade<F> evaluates to false. This prevents a non-enumerator value from having effect without changing the enumeration definition.

Constructor wording follow-up

I will adapt your copy and move constructor templates using current specification structure and omit redundant remarks about trivial copying.

Thank you again for the careful review.

[frederick-vs-ja]

Thanks! I don't think it would be reasonable to alter the enumeration, and we can simply said

F::copyability, F::relocatability, F::destructibility are core constant expressions of type constraint_level and each of them equals an enumerator of constraint_level.

Also, I recently found that the currently wording uses term "tuple-like" which seems to be defined in [tuple.like] in the standard. Is it really intended to allow any of "array, complex, pair, tuple, or ranges​::​subrange"?

[mingxwa]

Hi @frederick-vs-ja, thanks again for the suggestions. I agree with the wording improvements.

On "tuple-like": this wording came from a 2024 review comment (cplusplus/papers#1741 (comment)). I agree not all tuple-like types are useful for a facade definition (especially std::array), but the term is standard and the wording is harmless, so I'm keeping it for consistency.