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

[Dukc]

On Tuesday, 2 March 2021 at 20:46:17 UTC, Atila Neves wrote:
> On Monday, 1 March 2021 at 21:26:18 UTC, Paul Backus wrote:
>> On Monday, 1 March 2021 at 20:55:40 UTC, Atila Neves wrote:
>>> On Thursday, 25 February 2021 at 09:21:20 UTC, Mike Parker 
>>> wrote:
>>>> This is the discussion thread for the second round of 
>>>> Community Review of DIP 1035, "@system Variables":
>>>>
>>>> [...]
>>>
>>> "pointers, arrays, and other reference types are unsafe"
>>>
>>> This confused me. Pointers aren't unsafe unless you got one 
>>> from @system code. Could you clarify please?
>>
>> The language here is sloppy, but the intent is to refer to 
>> pointer *types*, not pointer *values*. It should read, 
>> "pointer types, dynamic array types, and other reference types 
>> are unsafe."
>
> Pointer types *can* be unsafe, if the values came from @system 
> code. Otherwise they're perfectly safe.

The correct wording to this is: pointer *values* can be unsafe if 
they come from `@system` code, therefore pointer *types* are 
unsafe, as defined by this DIP. When the DIP talks about unsafe 
type, it really means only potentially unsafe type.

> Slices (dynamic arrays) are slightly different because of the 
> necessity of bounds checks.

They are not. `(ubyte*).init[0xBAA..0xBEE]` is just as unsafe as 
`cast(int*)0xDEADBEEF`, regardless of whether there are bound 
checks when accessing it. Bounds checked access is safe only if 
the value is safe, just as with pointer dereference.

But deferencing a pointer is fine in @safe code - the
> possibilities are:
>
> * it came from the GC.
> * is the address of a module-level variable.
> * is a scoped address on the stack.
> * is null.
>
> Am I missing a case?

These are all true. The intention of the DIP is that you could 
make user-defined types that behave the same way - that `@safe` 
would guarantee they will not have unsafe values.

Think about defining a 16-bit pointer for 32-bit or 64-bit 
architecture. If you now declare it as `struct ptr16{private 
short handle;}` you will not be able to make it work in @safe 
code, as it can be void-initialized with wrong values. You'll 
have to do something like `union ptr16{short handle; void[2] 
unsafeMarker;}` instead.