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.