But we are modifying the override of B::lock.. lock_mutex isn't affected and doesn't become a different function, nor is the scope of "lock_mutex" affected by it.

Consider also:

using B::foo(int) override = foo(int);
using C::foo(int) override = foo(int);
using D::foo(int) override = bar(int);

The thing on the left side (function to override) can appear once. Whereas the other way around, it's the thing on the right side that can appear once, e.g. you can't do the following:

using foo(int) = B::bar(int);
using bar(int) = B::bar(int);

There is no logical problem with one function overriding multiple virtual base functions, but the other way around is impossible.

So I think you have it backwards, the thing that is being assigned is the override, not what the function overrides.

I hope you can agree that, with this case considered, it makes more sense for the override to be on the left side of the = symbol. Tell me your thoughts.

Also, I think using X override = Y; might need to be a separate proposal.

-------- Original Message --------
On Mar 19, 2020, 14:51, Michał Policht via Std-Proposals wrote:

>> I would go the other way around:
>>
>> using B::lock = lock_mutex();
>>
>
> 1. You should remain consistent with the rest of the language (i.e. type
> aliases).
> 2. Assigning it the other way around is confusing, because it suggests
> that you
> modify `B::lock`.
>
>> Also, the I believe the parameters need to be included if not the return
>> type.
>
> That should be a separate proposal - addressing `using` declarations.
>
>>
>> Or better,
>>
>> using override B::lock = lock_mutex();
>>
>> Or maybe
>>
>> using B::lock override = lock_mutex();
>>
>> As the last one might have less syntax conflict potential. Could "using
>> override X = Y;" cause a conflict? I prefer the first version if not.
>>
>
> IDK why do you want to put `override` there, if you can override aliased
> function with normal syntax.
>
> Regards,
> Michał
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals