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