dip1000 and preview in combine to cause extra safety errors

[John Colvin]

On Wednesday, 8 June 2022 at 16:58:41 UTC, deadalnix wrote:
> On Wednesday, 8 June 2022 at 16:32:25 UTC, John Colvin wrote:
>>> There is no frame of reference in which this result is in any 
>>> way reasonable.
>>
>> My guess is that technically `foo` has undefined behaviour.
>
> Sure, but that also mean it could format your hard drive, and 
> it'd be hard to argue this is reasonable.
>
> If the compiler understands of what's going on to decide it can 
> recycle the memory, it understands enough to tell you you are 
> using it after freeing and if it cannot, then it shouldn't do 
> it.
>
> In this case specifically, assuming the compiler see the memory 
> doesn't escape and promoting [c] on stack, it should still do 
> the right thing. That means the compiler is somehow getting out 
> of its way to break the code.
>
> That doesn't sound reasonable, no matter how you slice it.

The compiler is going “you told me `foo` doesn’t leak references 
to the string passed to it, I believe you. Based on that, this 
temporary array is safe to put on the stack”. I think it’s 
reasonable for the compiler to lean on `scope` like this.

The problem is `foo` and whether the compiler should somehow 
prevent the inconsistency between the signature and 
implementation. Obviously the answer is “yes, ideally”, but in 
practice with @safe, @system, dip1000, @live and so on it’s all a 
mess.