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

Andrei Alexandrescu SeeWebsiteForEmail at erdani.com
Wed Jun 17 14:27:17 UTC 2020


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. 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 main merit of this DIP is to bring attention to the problem and 
collect a list of issues to look at.

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.


More information about the Digitalmars-d mailing list