I am working with the internals of Clang and it doesn't look like a big
deal to add a token type to the template parser.

Whatever direction is taken, the resulting code need to syntactic sugar
as well.

-- 
*Phil Bouchard*
Founder
C.: (819) 328-4743
Fornux Logo <http://www.fornux.com>
On 9/29/19 2:15 PM, Gašper Ažman wrote:
> struct A {
>    int i;
>    template <std::convertible_to<A> Other> A& operator=(Other&& other) {
>        using A_cvref = copy_cvref_t<Other&&, A>;
>        i = static_cast<A_cvref>(other).i;
>        return *this;
>    }
> };
>
> No new features required, your example is pretty nice in the current 
> language already.
>
> copy_cvref_t is a metafunction that imposes the cvref qualifiers of 
> its first parameter to its second, and IMO should be standardized but 
> it's currently waiting for a proposal (from me), I've been a bit busy 
> with other things.
>
> When writing http://wg21.link/P0847 we have considered what you are 
> proposing at length and dismissed it as insufficiently general and way 
> too disruptive to the language vs. the effort of introducing another 
> token type into the template system and the entire type deduction 
> machinery.
>
> I'll gladly admit I'm wrong if you can prove it's simple to do and 
> integrate into the current language rules in a holistic manner, but 
> until then I remain unconvinced that it's a better solution than P0847.
>
>
> On Sun, Sep 29, 2019 at 7:01 PM Phil Bouchard <phil_at_[hidden] 
> <mailto:phil_at_[hidden]>> wrote:
>
>     Sorry I haven't read about recursive lambdas yet but here is a
>     better example in order to have unique functionality, including
>     move semantics:
>
>
>     struct A
>     {
>
>         int i;
>
>         A & operator = (A const & a) { i = a.i; return * this; }
>         A & operator = (A && a) { i = std::move(a.i); return * this; }
>         A volatile & operator = (A const & a) volatile { i = a.i;
>     return * this; }
>         A volatile & operator = (A && a) volatile { i =
>     std::move(a.i); return * this; }
>     };
>
>
>     struct A
>     {
>
>         int i;
>
>         template <qualifier Q, qualifier P>
>             A Q & operator = (A P a) Q { i = std::move_or_copy(a.i);
>     return * this; }
>     };
>
>
>     Where:
>
>     template <typename T>
>         typename std::remove_reference<T>::type & move_or_copy( T
>     const & t ) noexcept;
>
>     template <typename T>
>         typename std::remove_reference<T>::type && move_or_copy( T &&
>     t ) noexcept;
>
>
>     It follows the purpose of the "template" notion as well.
>
>
>     -- 
>
>     *Phil Bouchard*
>     Founder
>     C.: (819) 328-4743
>
>     Fornux Logo <http://www.fornux.com>
>
>
>     On 9/29/19 12:50 PM, Gašper Ažman wrote:
>>     This proposal introduces a new kind of entity - a qualifier -
>>     which will need to operate correctly with all parts of the
>>     language, and it does not solve the problem of recursive lambdas,
>>     nor all save the deduction of the qualifier that "deducing this"
>>     solves. I think there is a pretty large body of work required
>>     here before it's a better solution. All the other parameters can
>>     already be handled with existing metaprogramming, too.
>>
>>     Gašper
>>
>>     On Sun, Sep 29, 2019, 14:14 Phil Bouchard via Std-Proposals
>>     <std-proposals_at_[hidden]
>>     <mailto:std-proposals_at_[hidden]>> wrote:
>>
>>         The approach I propose is more generic as it can apply to all
>>         other parameters as well; not only "this".
>>
>>
>>         -- 
>>
>>         *Phil Bouchard*
>>         Founder
>>         C.: (819) 328-4743
>>
>>         Fornux Logo <http://www.fornux.com>
>>         -- 
>>         Std-Proposals mailing list
>>         Std-Proposals_at_[hidden]
>>         <mailto:Std-Proposals_at_[hidden]>
>>         https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>