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

[Paul Backus]

On Thursday, 4 March 2021 at 18:23:00 UTC, Atila Neves wrote:
> On Tuesday, 2 March 2021 at 21:41:40 UTC, Paul Backus wrote:
>>
>> 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.

I agree that the wording is confusing. In particular, the words 
"safe" and
"unsafe" are heavily overloaded. Unfortunately, "safe values" and 
"@safe code"
are both official language-spec terms, so there's nothing the DIP 
can do about
those.

It would probably still be helpful to replace "safe type" and 
"unsafe type" with
something more distinct. Maybe "unrestricted type" and 
"restricted type"? E.g.,

     Pointer *values* can be either safe or unsafe, depending on 
what they point
     to. Pointer *types* are always restricted types, because they 
include both
     safe and unsafe values.

A restricted type is any type which has limits placed on what you 
are allowed to do with it in @safe code. Hopefully it is clear 
that a type must be restricted if and only if it includes unsafe 
values.