On 2021-05-02 18:56, Arthur O'Dwyer wrote:

> Your proposal is very confused at the moment. I recommend showing a
> Tony Table: what does the code *for a real problem* look like before
> your proposal, and after it?

As the problem has already been described by Scott Meyers (referenced in
my draft) I had assumed that people were familiar with the problem, but
the replies in general have shown that I need to elaborate on the
motivation. I acknowledge that is my mistake.

> I emphasize "for a real problem" because the code you've showed above is
> not real: `alpha` is an empty struct, and you didn't provide the body of
> the "value constructor," so it's not clear to the reader what it's
> planning to do with the T&& it receives.

My draft contains four use-cases from the standard (std::any,
std::thread, std::range::common_view, and std::not_fn) and one ongoing
proposal (std::any_invocable.)

> implies that "is_value_constructible_v" is a property of `T` alone,
> whereas I assume you meant it to depend on `alpha` as well.

Yes. This error was introduced by a last minute edit. The associated
concepts example is correct though.

> However, I don't see any need to standardize is_same_uncvref; it seems
> trivial to write by hand.
> Notice I could also have done
> requires (not same_as<remove_cvref_t<T>, AlphableRef>)
> which is almost as short.

But not the same.

The full hand-written example is:

   requires (constructible_from<AlphableRef, T, Args...>
             and not same_as<remove_cvref_t<T>, AlphableRef)

With my proposal

   requires(value_constructible<AlphableRef, T, Args...>)

I am not too concerned about source code size though.

I want to provide a type trait that communicates intent.

I want to provide a type trait that can be used when you have a
templated constructor with forwarding references.

I want to provide a type trait that users can without knowing the exact
conditions themselves.

I want to provide a type trait that does not induce the cognitive
overload of negation or even double-negation to describe. For example,
instead of:

   "This constructor shall not participate in overload resolution unless
    V is not the same type as T" (slightly paraphrased from std::any)

we could describe it without double-negation as:

   "This constructor shall participate in overload resolution if T is
    value constructible with V"