On Thursday, 4 March 2021 at 18:47:28 UTC, Steven Schveighoffer wrote:
> On 3/4/21 1:23 PM, Atila Neves wrote:
>> [...]
>
> 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

That makes sense, but I'm not sure that's how we *should* define it, given that pointers are memory-safe in @safe code.

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.

On 2/25/21 4:21 AM, Mike Parker wrote:
> This is the discussion thread for the second round of Community Review of DIP 1035, "@system Variables":
> 
> https://github.com/dlang/DIPs/blob/c39f6ac62210e0604dcee99b0092c1930839f93a/DIPs/DIP1035.md 
> 
> 

In the example for (2):

struct Handle {
    @system int handle;
}

// struct with @system field is an unsafe type
@safe   Handle safeHandle = Handle(1);
@system Handle systemHandle = Handle(-1);

...

void main() @safe {
    Handle h0 = safeHandle;        // allowed, @safe variable
    Handle h1 = systemHandle;      // error, reading @system var of unsafe type
    ...
}

I'm concerned about the allowance of just declaring a @safe Handle.

If Handle(-1) is unsafe, what is stopping me from doing:

@safe Handle sneakyHandle = Handle(-1);

And can I just do this inside main():

   Handle h2 = Handle(-1);

I guess my biggest problem with this DIP is surrounding the allowance of initialization of @system variables without requiring a @system call. And/or the weird rules of "you can't do it if it's a @system variable, but perfectly fine if you type out the initializer"

Or maybe I'm misunderstanding something. Perhaps it would be good to specify how one prevents anything in @safe from using Handle(-1).

------

Another note, the ShortString example is unsafe, even with the DIP, as `s[]` will provide access to data that might move elsewhere.

Perhaps it would be good to restate the examples with the assumption the DIP is implemented, and show why they are now fully @safe.

-Steve

On Thursday, 4 March 2021 at 20:10:05 UTC, Steven Schveighoffer wrote:
> In the example for (2):
>
> struct Handle {
>     @system int handle;
> }
[...]
> If Handle(-1) is unsafe, what is stopping me from doing:
>
> @safe Handle sneakyHandle = Handle(-1);

Nothing, because Handle(-1) isn't unsafe. If your next question is "then why use a @system variable?", the answer is that this isn't intended to be a realistic example. It's just an illustration of the semantics of @system variables.

If you actually wanted to maintain an invariant like "Handles can't be negative", you would have to write a constructor:

struct Handle {
    @system int handle;
    this(int n) @safe {
        assert(n >= 0);
        handle = n;
    }
}

> Another note, the ShortString example is unsafe, even with the DIP, as `s[]` will provide access to data that might move elsewhere.

ShortString doesn't contain internal pointers, and the compiler won't let `s[]` outlive the ShortString's lexical scope, which means that the problem in issue 17448 [1] can't happen here. So it should be fine, unless there's something else I'm missing.

It does require DIP 1000, which means that opIndex should be annotated with `return`.

[1] https://issues.dlang.org/show_bug.cgi?id=17448