how much "real-life" code can be marked @safe ?

[Alexandru Ermicioi]

On Saturday, 3 July 2021 at 20:09:56 UTC, tsbockman wrote:
> On Saturday, 3 July 2021 at 16:06:33 UTC, Alexandru Ermicioi 
> wrote:
>> 3. An edge case. Ex: You need to mutate some data and then 
>> assume it is immutable in a constructor.
>
> Can you give a valid example where that is necessary? The main 
> examples that I can think of either can be `@safe` with the 
> right API, or are motivated by a desire to avoid the GC and/or 
> druntime, thus falling under (1).

Can't remember any specific code now, but suppose you have a 
mutable object as input to a function or constructor. You need to 
return or assign an immutable copy of that struct and you can do 
that with right copy constructor on that object, but before that 
you need to do a couple of mutations on that object. In this use 
case you can't avoid cast(immutable) easily. Note: it is desired 
to not mutate the original object.

The summary is this: the construction of immutable instances can 
be done just through initialization statement. You can't mutate 
the instance and then assign/assume it as an immutable.

>> 4. Functionality that doesn't account for @safe/immutable or 
>> any other features when it can in standard library.
>
> True, although it's just another example of my point (2). The 
> standard library and druntime are dependencies, too...

Right, didn't take it that way.

>
> The one exception here is when the array is already typed 
> `inout` before it is passed to the constructor. But, that's an 
> example of (2) since this logic applies transitively throughout 
> the call stack: if you need to call `dup` anywhere, don't erase 
> the constness with `inout`.

Yeah this is a working workaround, for this specific use case. I 
still would prefer inout version, even if I need to do some 
unsafe casts due to clear intentions it gives the user, and 
better errors.
Anyway this is just a proof of your 2nd point.