On Saturday, 5 February 2022 at 03:02:37 UTC, forkit wrote:
On Friday, 4 February 2022 at 15:58:19 UTC, Stanislav Blinov
wrote:
..
...
As others have already stated, casting immutability away is
something that has to be supported, e.g. to interface with
const-agnostic APIs. `@safe` requires such casts to be more
verbose, with good reason.
I concede ;-)
That the compiler knows this is @safe:
cast(char[])iStr.dup;
and this is not @safe:
cast(char[])iStr;
is sufficent.
The compiler doesn't know what you think it knows in this
scenario.
It doesn't know what function you intended to use originally, in
this case .dup.
So what do you expect the compiler to tell you when you do the
following?
```d
cast(char[])iStr
```
It's not actually invalid code and only invalid under @safe IFF
the result is mutated.
To the compiler everything is actually fine in that scenario.
The compiler also doesn't know that when you cast to char[] that
you want to get a mutable duplicate of the string, because it
doesn't have such a concept. It doesn't know .dup is actually the
function you want to call, because there could be an ocean of
different functions that you want to call that returns a mutable
reference of the type.
In fact by giving it a cast you tell the compiler "I know what
type this really is" and thus the compiler just says "okay". It
won't complain when you tell it you know what you're doing,
similarly to calling a @trusted function under @safe, you tell
the compiler "I know this function is safe, even though it's not
marked as safe" and thus the compiler will not actually complain
if the function wasn't safe.