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