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.