Discussion Thread: DIP 1035-- at system Variables--Community Review Round 2

[Paul Backus]

On Tuesday, 2 March 2021 at 14:28:43 UTC, Dukc wrote:
> On Tuesday, 2 March 2021 at 14:09:01 UTC, Paul Backus wrote:
>> Good point. For user-defined unsafe types like ShortString, 
>> the compiler will have to assume that any value that can be 
>> obtained in @safe code is a safe value.
>
> But what about determining `@safe`ty of value given by 
> `@system` initializer? Is it just not attempted for 
> user-defined types? Or is the rule "`.init` value is `@safe`, 
> everything else is `@system`"? Or something more complicated?

I think you may be confusing the safety of a *value* with the 
safety of a *variable*.

Consider the following example:

     @safe ShortString makeShortString(string source) { /* ... */ }

     auto s = makeShortString("hello");

The value of `makeShortString("hello")` is *assumed* to be a safe 
value, because `makeShortString` is a @safe function. Therefore, 
the variable `s` is *determined* to be a @safe variable, because 
its initializer is a safe value.

Regarding `.init`: because default initialization of any type is 
allowed in @safe code, the `.init` value of any user-defined type 
must be a safe value. This is true today, and it will still be 
true if DIP 1035 is accepted. The fact that the compiler 
currently does not enforce this is a bug. [1]

[1] https://issues.dlang.org/show_bug.cgi?id=21675