How do I use `__rvalue` expression on a struct property?
Manu
turkeyman at gmail.com
Tue Apr 29 12:54:37 UTC 2025
On Mon, 28 Apr 2025 at 03:26, Timon Gehr via Digitalmars-d <
digitalmars-d at puremagic.com> wrote:
> On 4/27/25 04:01, Manu wrote:
> > Yes, but like I've said to you before, they're problematic and find
> > themselves interfering with the situation frequently.
> > It's possible to reconcile this, but I agree it would be better to move
> > away... but that's very hard to do in practise.
> > postblit has innertia, and failure to implement copy/move constructors
> > because of an interaction with postblit tends to lead to resolving the
> > issue by writing another postblit... that doesn't lead us in the right
> > direction.
>
> I think ideally this would be resolved by simply generating a copy
> constructor that calls the postblit if there is a postblit and
> generating a disabled copy constructor if the postblit is disabled.
> Then, can just delete all existing postblit-related logic from the
> compiler source.
>
> Of course, one issue here is that postblit is not type safe/memory safe.
> So in the long run, would be better to get rid of them or restrict them
> to work only for mutable copies unless they are `pure`.
>
> I tend to find postblit convenient enough in the cases where it is
> sufficiently expressive, so I would be somewhat sad to see them go
> completely, but I understand some of the arguments in favor of that.
>
Yes exactly... all these things you say.
We will need default (element-wise) copy/move constructors, and they need
to call through to postblits for members with postblits, and that should
position us in a place where we don't continue to proliferate postblits,
and we can eventually deprecate.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20250429/954e9ca6/attachment.htm>
More information about the Digitalmars-d
mailing list