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

[WebFreak001]

On Wednesday, 10 June 2020 at 08:38:31 UTC, Mike Parker wrote:
> This is the discussion thread for the first round of Community 
> Review of DIP 1035, "@system Variables":
>
> https://github.com/dlang/DIPs/blob/148c78e6e7eeb5609715cb31a45c0aa5c8ebdce7/DIPs/DIP1035.md
>
> [...]

I really like the idea of having safety on variables instead of 
trying to protect it with private as it makes @safe much harder 
to accidentally abuse in a single file or with traits. I really 
like the DIP but I don't think the changes to 
__traits(getFunctionAttributes) might be worth any breakage and 
the inferring of safety on initial assignment "when the compiler 
knows that a function is safe" is kind of going against the 
current attribute inferring implementation in D.

First I propose a solution to this problem:

struct Wrapper(T) {
     @system T t;
     this(T t) @trusted {
         this.t = t; // Oops! Calls a `@system` copy constructor
     }
}

I don't see a solution proposed to this pitfall in the DIP but 
wouldn't this be solvable from a library function? Something like

ref T trustedAssign(T)(const return ref T value) @trusted { 
return *cast(T*)&value; }

struct Wrapper(T) {
     @system T t;
     this(T t) @safe {
         this.t.trustedAssign = t; // "cast away @system"
     }
}

Well considering dip1000 and other factors the function might not 
be this trivial but the general idea of having a function to 
access @system as @trusted/@safe would work, no?


> __traits(getFunctionAttributes) may be called on variables and 
> fields

regarding this: I would like to keep getFunctionAttributes away 
just in case someone __traits(compiles) it to check for a 
function. (sounds like a reasonable enough thing someone would do 
I think)


> bool getValidBool()   pure @system {return true;}
> bool getInvalidBool() pure @system {return *(cast(bool*) &ub);}
> 
> bool b0 = getValidBool();   // despite unsafe type with @system 
> initialization expression, inferred as @safe
> bool b1 = getInvalidBool(); // inferred as system

and

> Variables and fields without annotation are @safe unless their 
> initial value is not @safe
> [...]
> An exception to the above rules is made on unsafe types when 
> the compiler knows the resulting value is safe.

I think this doesn't fit into how D currently infers attributes. 
Instead the @system should probably be part of the return type in 
some way. Otherwise this is making it not possible to use a D 
library using a .di file the same as using a .d file (which 
currently works fine) - For template functions this is fine like 
all other attributes are inferred but for normal functions I 
think this is some kind of inferring we don't want to start. 
Maybe a possible solution would be having the safety as some kind 
of attribute on the return type, but I'm not too sure on that.