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