Actual lifetime of static array slices?

[Paul Backus]

On Tuesday, 15 November 2022 at 14:05:42 UTC, Siarhei Siamashka 
wrote:
> On Tuesday, 15 November 2022 at 13:16:18 UTC, Paul Backus wrote:
>> D's safety model is the same. In `@safe` code, D will reject 
>> anything that the compiler cannot say for sure is memory safe. 
>> However, unlike in Rust, `@safe` is not the default in D, so 
>> you must mark your code as `@safe` manually if you want to 
>> benefit from these checks.
>
> I specifically asked for Ali's opinion. Because the context is 
> that the compiler couldn't catch a memory safety bug in the 
> code that was annotated as @safe (but without -dip1000) and Ali 
> commented that "the compiler cannot do anything about it in all 
> cases and we wouldn't want it to spend infinite amount of time 
> to try to determine everything". This sounds like he justifies 
> the compiler's failure and accepts this as something normal.
>
> The https://dlang.org/spec/memory-safe-d.html page also 
> provides a rather vague statement: "@safe functions have a 
> number of restrictions on what they may do and are intended to 
> disallow operations that may cause memory corruption". Which 
> kinda means that it makes some effort to catch some memory 
> safety bugs. This weasel language isn't very reassuring, 
> compared to a very clear Rust documentation.

The goal of `@safe` is to ensure that memory corruption cannot 
possibly occur in `@safe` code, period--only in `@system` or 
`@trusted` code. If the documentation isn't clear about this, 
that's failure of the documentation.

However, there are some known issues with `@safe` that require 
breaking changes to fix, and to make migration easier for 
existing code, those changes have been hidden behind the 
`-dip1000` flag. So in practice, if you are using `@safe` without 
`-dip1000`, you may run into compiler bugs that compromise memory 
safety.

That's what happened in your example. Slicing a stack-allocated 
static array *shouldn't* be allowed in `@safe` code without 
`-dip1000`, but the compiler allows it anyway, due to a bug, and 
the fix for that bug is enabled by the `-dip1000` switch.