On 10/17/24 15:11, Timon Gehr wrote:
>
>
>> Can you explain to me how every other function call isn't broken under
>> the special-case-for-move-constructor solution?
>
> Move semantics still needs a separate solution, but this thread is about
> move constructors. Move constructors are not needed for move semantics,
> they are needed to manually hook moves that involve a transfer of values
> between different memory locations.
Maybe here part of your question was why special-casing move
constructors solves the overload resolution issue? The issue is an
implementation detail that no longer occurs when move constructor and
copy constructor are not functions in the same overload set.
I understand it's an implementation challenge; Razvan talked about it a bit, but it's the same implementation challenge as any normal function overloaded the same way afaict. It has to be solved in general.
...at which point, the problem will already have been resolved with respect to the constructor too, and none of this discussion about the constructor actually exists. The general solution naturally solves the constructor case without any additional attention.
I don't think you should talk about the hack as if it's worthy of attention, because the rest of the work naturally factors this problem out of existence, so it's all just a misleading waste of thought and breath. It seems to be confusing people fundamentally.
I think it is a nice side-effect that this problem is fixed, but it
should not be the main motivation for special move constructor syntax.
It's a hack, and I actually think it's just basically counterproductive to humour this train of thought, because it seems to be perpetuating confusion and leading people away from understanding what move semantics even are. Help them arrive at the understanding that this issue doesn't actually exist, and doesn't require a 'solution'.