[func.wrap.ref.deduct] simplify wording

[zhihaoy]

No description provided.

[frederick-vs-ja]

This seems to be a functional change and thus perhaps requires an LWG issue.

The 2nd template argument of constant_wrapper is possibly provided by the user (and thus can be a function type whatever c is), and the change will affect such (pathological, IMO) uses. Presumably these deduction guides should rely on constant_wrapper::value_type.

[eisenwave]

Yeah right, https://eel.is/c++draft/const.wrap.class#lib:constant_wrapper doesn't put any Constraints or Mandates on the second template parameter; so it could be literally anything.

Concretely, the proposed change makes it invalid to use the deduction guide with constant_wrapper</* ... */, int()> because remove_pointer_t accepts non-pointers, but F* would fail deduction.

[zhihaoy]

Concretely, the proposed change makes it invalid to use the deduction guide with constant_wrapper</* ... */, int()> because remove_pointer_t accepts non-pointers, but F* would fail deduction.

Then we got a bigger problem: function_ref(std::constant_wrapper<nullptr, int()>{}) can bypass the ctor's Mandates and break the class invariant.

[eisenwave]

@zhihaoy Have you submitted an LWG issue yet?

[lichray]

@zhihaoy Have you submitted an LWG issue yet?

Now sent.

[frederick-vs-ja]

P4206R0 seems relevant to this.

[zhihaoy]

P4206R0 seems relevant to this.

Yes, it happens to offer a drive-by fix for the issue I sent.

[jwakely]

Yes:

If a specialization of constant_wrapper is instantiated with a type T such that is_same_v<T, value_type> is false, the program is ill-formed.