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

Stanislav Blinov stanislav.blinov at gmail.com
Wed Jun 17 13:19:53 UTC 2020


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. Private or no private, writing to it is not @safe no matter 
where you do it.
No SysVar!insert_all_your_types_here all over the binary; no 
associated runtime costs (i.e. copies for and in get/set); no 
associated implementation costs (at least in current language, 
until such time that moves do get realized).


More information about the Digitalmars-d mailing list