<div dir="ltr"><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Mon, 28 Apr 2025 at 03:26, Timon Gehr via Digitalmars-d <<a href="mailto:digitalmars-d@puremagic.com">digitalmars-d@puremagic.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 4/27/25 04:01, Manu wrote:<br>
> Yes, but like I've said to you before, they're problematic and find <br>
> themselves interfering with the situation frequently.<br>
> It's possible to reconcile this, but I agree it would be better to move <br>
> away... but that's very hard to do in practise.<br>
> postblit has innertia, and failure to implement copy/move constructors <br>
> because of an interaction with postblit tends to lead to resolving the <br>
> issue by writing another postblit... that doesn't lead us in the right <br>
> direction.<br>
<br>
I think ideally this would be resolved by simply generating a copy <br>
constructor that calls the postblit if there is a postblit and <br>
generating a disabled copy constructor if the postblit is disabled. <br>
Then, can just delete all existing postblit-related logic from the <br>
compiler source.<br>
<br>
Of course, one issue here is that postblit is not type safe/memory safe. <br>
So in the long run, would be better to get rid of them or restrict them <br>
to work only for mutable copies unless they are `pure`.<br>
<br>
I tend to find postblit convenient enough in the cases where it is <br>
sufficiently expressive, so I would be somewhat sad to see them go <br>
completely, but I understand some of the arguments in favor of that.<br></blockquote><div><br></div><div>Yes exactly... all these things you say.</div><div>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.</div></div></div>