DIP1028 - Rationale for accepting as is

Arafel er.krali at gmail.com
Sat May 23 23:03:42 UTC 2020


On 24/5/20 0:38, ag0aep6g wrote:
> On 24.05.20 00:17, Arafel wrote:
>> On 24/5/20 0:02, ag0aep6g wrote:
>>>
>>> ... and @system static constructors and `--boundscheck=off` and 
>>> initializers of globals
>>
>> Other than `--boundscheck=off`, that is presumably actively chosen by 
>> the user (as is @trust), would the others be allowed without 
>> `@trusted` in otherwise 100% @safe code?
> 
> Yup. Today they can be unmarked, defaulting to @system. With DIP 1028, 
> they can be explicitly marked @system. Either way, they don't show up 
> when you only look for "@trusted".
> 
>> I would find concerning that any @system code is allowed, but I guess 
>> initializers of globals should be ok as long as they are @safe 
>> themselves?
> 
> As long as they're @safe, sure. But they can also be @system.
> 
> An example:
> ----
> const int x = 42;
> const int y = 43;
> 
> void main() @safe
> {
>      import std.stdio;
>      writeln(x, " ", y); /* Prints "42 43" as expected. */
>      auto px = &x;
>      auto py = &y;
>      writeln(*px, " ", *py); /* Prints "13 14". Wat? */
> }
> 
> int* p = cast(int*) &x;
> static this() @system { *p = 13; *++p = 14; }
> ----
> 

I find this... disturbing... what is worse, it also happens with 
`immutable`.

Then there should most definitely be a list of features to look (in 
addition to `@trusted`) if you want to make sure your `@safe` code is 
actually safe.


More information about the Digitalmars-d-announce mailing list