Thread overview
what was the problem with the old post blit operator already ?
Feb 15
Basile B.
Feb 15
Basile B.
Feb 15
Basile B.
Feb 15
Kagamin
February 15

From what I remember, it was that there was no reference to the source. Things got blitted and you had to fix the copy, already blitted. Was that the only issue ?

February 14
On Thu, Feb 15, 2024 at 02:17:15AM +0000, Basile B. via Digitalmars-d-learn wrote:
> From what I remember, it was that there was no reference to the source.  Things got blitted and you had to fix the copy, already blitted. Was that the only issue ?

I don't quite remember all of the reasons now. But yeah, one of the problems with postblit was that you don't have access to the original copy. That precludes some applications where you need to look up data from the original or update the original.

And if you have immutable fields they've already been blitted and you can't fix them anymore, not without casting away immutable and putting yourself in UB zone.

There may have been other issues with postblit, I don't quite remember now.


T

-- 
Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald Knuth
February 14
On Wednesday, February 14, 2024 7:17:15 PM MST Basile B. via Digitalmars-d- learn wrote:
>  From what I remember, it was that there was no reference to the
> source. Things got blitted and you had to fix the copy, already
> blitted. Was that the only issue ?

There were probably some use cases where you needed access to both the source and the destination so that you could do something to the source as well, but the core problem was simply that blitting and then mutating the copy to fix it doesn't work with const or immutable objects, since it would violate the type system to cast away const or immutable to fix the copy. The only way to work properly with const or immutable is to construct the object with the changes in the first place rather than mutating the copy after the fact.

- Jonathan M Davis



February 15
On Thursday, 15 February 2024 at 02:29:27 UTC, H. S. Teoh wrote:
> On Thu, Feb 15, 2024 at 02:17:15AM +0000, Basile B. via Digitalmars-d-learn wrote:
>> From what I remember, it was that there was no reference to the source.  Things got blitted and you had to fix the copy, already blitted. Was that the only issue ?
>
> [...]
> And if you have immutable fields they've already been blitted and you can't fix them anymore, not without casting away immutable and putting yourself in UB zone.
>
> [...]
> T

Ah those type qualifiers. Always at the corner, ready to eat your face.
February 15
On Thursday, 15 February 2024 at 03:17:11 UTC, Jonathan M Davis wrote:
> On Wednesday, February 14, 2024 7:17:15 PM MST Basile B. via Digitalmars-d- learn wrote:
>>  From what I remember, it was that there was no reference to the
>> source. Things got blitted and you had to fix the copy, already
>> blitted. Was that the only issue ?
>
> There were probably some use cases where you needed access to both the source and the destination so that you could do something to the source as well, but the core problem was simply that blitting and then mutating the copy to fix it doesn't work with const or immutable objects, since it would violate the type system to cast away const or immutable to fix the copy. The only way to work properly with const or immutable is to construct the object with the changes in the first place rather than mutating the copy after the fact.
>
> - Jonathan M Davis

That point was raised by Teoh too, which raises another question. Did the "old" postblit exist before the introduction of type qualifiers ? I think to D1 obviously.

That would suggest that the introduction of type qualifiers was not perfectly executed, i.e some aspects were not mastered, until, years after, someone said "wait a minute, there's something wrong".
February 15
It was mostly fine, such types are not supposed to be immutable, but recently came an idea of reference counted strings, which need to be immutable for being strings.