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

[Steven Schveighoffer]

On 3/4/21 1:23 PM, Atila Neves wrote:
> On Tuesday, 2 March 2021 at 21:41:40 UTC, Paul Backus wrote:
>> On Tuesday, 2 March 2021 at 20:46:17 UTC, Atila Neves wrote:
>>> Pointer types *can* be unsafe, if the values came from @system code. 
>>> Otherwise they're perfectly safe. Slices (dynamic arrays) are 
>>> slightly different because of the necessity of bounds checks. 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?
>>
>> You are conflating types and values. Pointer *values* can be either 
>> safe or unsafe, depending on what they point to. Pointer *types* are 
>> always unsafe, because they include both safe and unsafe values.
> 
> I don't think I am, but I think I understand where you're coming from. 
> Let me restate my point and maybe then it will be clearer: if all the 
> code in a program is @safe, then pointers are memory safe (with DIP1000).
> 
> I guess I'd argue that pointer types are safe unless the value was 
> obtained from @system code. But throw @system code into the mix...
> 
> Anyway, the wording confused me.
> 

At the very top of the DIP:

"D's memory safety system distinguishes between safe values, which can 
be used freely in @safe code without causing undefined behavior, and 
unsafe values, which cannot. A type that has only safe values is a safe 
type; one that has both safe and unsafe values is an unsafe type."

Unsaid here is that it doesn't matter where it comes from (@safe or 
@system). This is how they are defining "safe types" and "unsafe types". 
Everything follows from that.

Given that definition, pointers are unsafe.

-Steve