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

[Dennis]

On Wednesday, 10 June 2020 at 10:00:40 UTC, WebFreak001 wrote:
> 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

The currently proposed solution is to not mark the constructor 
@trusted but @safe.

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

Such a function is easily abused.
```
void main() @safe {
     immutable x = 3;
     x.trustedAssign = 7;
}
```

> 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?

There is control flow checking in the constructor that does not 
go across function boundaries, so I think it would require an 
intrinsic or language change.

> 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)

That's fair. I'll change that.

> 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.

I don't want this code to break because `x` becomes @system here:
```
bool foo() {return true;} // @system function by default
bool x = foo();
```

To me it's similar to value range propagation.
```
short x0 = cast(short) 500; // allowed, cast int to short
short x1 = 500; // also allowed, compiler knows value is in range
```

> 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)

It's not possible to initialize variables from extern functions 
anyway:

```
bool foo();
bool x = foo();
```

Error: foo cannot be interpreted at compile time, because it has 
no available source code

> 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.

The return value of a @system function is deemed @system in the 
general case, but if a @system function returns a bool `false` or 
`true` at compile time I see no reason to still pretend it may be 
an invalid bool.