Move Constructor Syntax

Manu turkeyman at gmail.com
Thu Oct 17 15:16:36 UTC 2024


On Thu, 17 Oct 2024, 23:17 Timon Gehr via Digitalmars-d, <
digitalmars-d at puremagic.com> wrote:

> 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'.

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20241018/232916df/attachment.htm>


More information about the Digitalmars-d mailing list