@trusted assumptions about @safe code

[ag0aep6g]

On 26.05.20 01:47, Dukc wrote:
> No, `f` should be just dead `@system`. If you call f with a string which 
> does not point to null, but is empty, boom!

Right. I can fix that by changing

     immutable(char)* c = s.ptr;

to

     immutable(char)* c = &s[0];

correct?

[...]
> I don't think it as a problem for `@safe`. `@safe` is just a command to 
> turn the memory checking tool on, not a code certification (although 
> using @safe where possible would probably be required for certifying). 

And you don't think it's possible and worthwhile to strengthen @safe so 
far that it becomes a code certification?

> Combating the scenarios you mentioned means that the `@safe` function 
> called must be at least as certified as the `@trusted` caller, but that 
> is no reason to forbid using the memory checking tool the language offers.

In my scenario, the @safe function is (supposed to be) perfectly safe 
before and after the catastrophic change. You can try certifying it 
beyond what the compiler does, but there's really nothing wrong with the 
function.

The thing is that editing the @safe function affects the status of the 
@trusted one. And I think it should be possible to tweak the rules so 
that a correctly verified @trusted function cannot become invalid when 
something changes in a called @safe function.