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

[Stanislav Blinov]

On Wednesday, 17 June 2020 at 14:27:17 UTC, Andrei Alexandrescu 
wrote:
> On 6/17/20 9:19 AM, Stanislav Blinov wrote:
>> On Wednesday, 17 June 2020 at 12:41:57 UTC, Andrei 
>> Alexandrescu wrote:
>>> On 6/17/20 2:14 AM, Timon Gehr wrote:
>>>>
>>>>> Embellishments are immediate (ctors, allowing void init, 
>>>>> opAssign, etc). To the extent this type can be pried open 
>>>>> in @safe code, these are definitely bugs in the existing 
>>>>> language.
>>>>
>>>> Not all of them, though the fact that it has a default 
>>>> constructor `this(T value){ this.value = value; }` is a bug.
>>>
>>> Ehm. The structure given was a minimal sketch, not an attempt 
>>> at a complete implementation. An implementation could choose 
>>> to disable the constructor or define it as @system etc.
>> 
>> ...or the language would do all that work for you, under this 
>> DIP; no new user types required, no ctors/dtors/sets/gets, 
>> merely a @system in front of a variable. That something *can* 
>> be a library solution does not mean that it *should* be one 
>> (*cough* emplace *cough* move *cough*). The DIP *is* a 
>> solution to many of the "bugs" with @safe.
>> 
>> Writing @safe code in a module should be no different to 
>> writing @safe code outside that module.
>> 
>> @system int x;
>> 
>> Done.
>
> Not even close.

Ahem. As opposed to your SysVar!T? Very close. Very, very, very 
close.

> The crux of the matter is that forgetting to add @system to 
> that variable makes @safe code do unsafe things with no 
> diagnostic for the compiler. That's a problem with the safety 
> system, regardless of the adoption of this DIP. We can't say 
> "@safe D code is safe, except of course if you forget to insert 
> @system on key variables, in which case it won't be with no 
> warning."

The same holds for SysVar!int, only with added burdens both on 
the programmer and on the compiler. Plus, if you are considering 
the forgetfulness rhetoric, one might as well forget to put a 
@safe on a function, potentially with the same consequences.
int is, inherently, a safe type, therefore programmer's 
forgetfulness in this case cannot be a consideration for the 
compiler: that's what review is for.

> The main merit of this DIP is to bring attention to the problem 
> and collect a list of issues to look at.

...while providing a generalized solution to a whole bunch of 
them.

> Coming from the other side: assume all bugs in @safe mentioned 
> in the DIP are fixed (as they should anyway) - the question is 
> what would be the usefulness of it then. I think a DIP listing 
> the bugs and then motivating its necessity without assuming 
> they won't be fixed would be stronger.

It will enable the programmer to express unsafe types and unsafe 
values when the compiler would not infer them as such, *without 
requiring the programmer to concoct arbitrary wrappers*, such as 
the SysVar!T.