Re: what was the problem with the old post blit operator already ?
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".
Re: what was the problem with the old post blit operator already ?
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
Re: what was the problem with the old post blit operator already ?
On Thu, Feb 15, 2024 at 02:17:15AM +, 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
Re: std.string.assumeUTF() silently casting mutable to immutable?
On Wednesday, 14 February 2024 at 11:56:29 UTC, Forest wrote:
On Wednesday, 14 February 2024 at 10:57:42 UTC, RazvanN wrote:
This has already been fixed, you just need to use
-preview=fixImmutableConv. This was put behind a preview flag
as it introduces a breaking change.
I just tried that flag on run.dlang.org, and although it fixes
the case I posted earlier, it doesn't fix this one:
```d
string test(const(ubyte)[] arr)
{
import std.string;
return arr.assumeUTF;
}
```
Shouldn't this be rejected as well?
Indeed, that should be rejected as well, otherwise you can modify
immutable table. This code currently happily compiles:
```d
string test(const(ubyte)[] arr)
{
import std.string;
return arr.assumeUTF;
}
void main()
{
import std.stdio;
ubyte[] arr = ['a', 'b', 'c'];
auto t = test(arr);
writeln(t);
arr[0] = 'x';
writeln(t);
}
```
And prints:
```
abc
xbc
```
However, this seems to be a different issue.
Re: std.string.assumeUTF() silently casting mutable to immutable?
On Wednesday, 14 February 2024 at 10:57:42 UTC, RazvanN wrote:
This has already been fixed, you just need to use
-preview=fixImmutableConv. This was put behind a preview flag
as it introduces a breaking change.
I just tried that flag on run.dlang.org, and although it fixes
the case I posted earlier, it doesn't fix this one:
```d
string test(const(ubyte)[] arr)
{
import std.string;
return arr.assumeUTF;
}
```
Shouldn't this be rejected as well?
