On Thursday, 25 February 2021 at 09:21:20 UTC, Mike Parker wrote:
>
> The review period will end at 11:59 PM ET on March 11, or when I make a post declaring it complete. Discussion in this thread may continue beyond that point.
>
> Here in the discussion thread, you are free to discuss anything and everything related to the DIP. Express your support or opposition, debate alternatives, argue the merits, etc.
>

So, in a few words, the merit of the DIP is that after this change, you have to review only @trusted functions to ensure a @safe function hasn't broken an invariant of the aggregate.

Which is strange to me since I was under the impression @safe/@trusted was only about memory safety. But in a way it makes sense to use it for "general bugs" since @trusted function will be audited. So, no real opinion here. Why not.

On 02.03.21 23:15, Guillaume Piolat wrote:
> On Thursday, 25 February 2021 at 09:21:20 UTC, Mike Parker wrote:
>>
>> The review period will end at 11:59 PM ET on March 11, or when I make a post declaring it complete. Discussion in this thread may continue beyond that point.
>>
>> Here in the discussion thread, you are free to discuss anything and everything related to the DIP. Express your support or opposition, debate alternatives, argue the merits, etc.
>>
> 
> So, in a few words, the merit of the DIP is that after this change, you have to review only @trusted functions to ensure a @safe function hasn't broken an invariant of the aggregate.
> 
> Which is strange to me since I was under the impression @safe/@trusted was only about memory safety. But in a way it makes sense to use it for "general bugs" since @trusted function will be audited. So, no real opinion here. Why not.

@system variables are still about memory safety.

On Tuesday, 2 March 2021 at 22:06:30 UTC, Ola Fosheim Grøstad 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.
>
> A type-system can be made to distinguish between safe and unsafe pointers.
>
> A type is just a tag stuck onto a value.

For example, Active Oberon, Modula-3, C#, F#, Swift, Go, all have this pointer distinction.

Pointers are always safe, unless explicitly marked otherwise or used in unsafe contexts, converting between both types is also explicit.

On Tuesday, 2 March 2021 at 15:34:31 UTC, Dukc wrote:
> How is this piece from the rationale section describing the situation before DIP1035?
>
> "Since the initialization expression cast(int*) 0xDEADBEEF would not be allowed in a @safe function, and since the initial value of y is unknown, the compiler should annotate variables x and y as possibly containing an unsafe value, so they cannot be accessed in a @safe function. Only z is known to have a safe initial value in this case, so the compiler could allow access to it in @safe code."

I don't understand the question. Is there a contradiction in that paragraph I'm supposed to see? Note that the description is about what the compiler _should_ do given the current language semantics, not what dmd actually does. The version of the DIP from the previous review round acknowledged existing holes in @safe and was critiqued for it, so this version tries to use the language specification as a base rather than the implementation. (Though that's not always easy, since the specification is lacking in certain areas as well)

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.

On Wednesday, 3 March 2021 at 10:05:34 UTC, Dennis wrote:
> On Tuesday, 2 March 2021 at 15:34:31 UTC, Dukc wrote:
>> How is this piece from the rationale section describing the situation before DIP1035?
>>
>> [snip]
>
> I don't understand the question.

Don't worry, I think you managed to answer it anyway.

> Is there a contradiction in that paragraph I'm supposed to see? Note that the description is about what the compiler _should_ do given the current language semantics, not what dmd actually does.

That explains it. I thought that since the dip says "should" and dmd currently does not do it (interpreting `extern int*` as `@system`), I thought it was explaining what the DIP will do. My misunderstanding, though changing a few words might be in order to avoid this confusion.

On 3/2/21 5:15 PM, Guillaume Piolat wrote:
> On Thursday, 25 February 2021 at 09:21:20 UTC, Mike Parker wrote:
>>
>> The review period will end at 11:59 PM ET on March 11, or when I make a post declaring it complete. Discussion in this thread may continue beyond that point.
>>
>> Here in the discussion thread, you are free to discuss anything and everything related to the DIP. Express your support or opposition, debate alternatives, argue the merits, etc.
>>
> 
> So, in a few words, the merit of the DIP is that after this change, you have to review only @trusted functions to ensure a @safe function hasn't broken an invariant of the aggregate.

I would change this to "you can make it possible" to only have to review @trusted functions. Without actually marking the variables @system, you would still have to review @safe code.

> Which is strange to me since I was under the impression @safe/@trusted was only about memory safety. But in a way it makes sense to use it for "general bugs" since @trusted function will be audited. So, no real opinion here. Why not.

Inside a @trusted function, you can assume that any data entering the function is only set to values that obey the @safe rules. Currently, that means certain invariants cannot be realized (like that a length field identifies how many bytes are valid past a pointer field).

This DIP allows you to restrict the rules further so more assumptions can be made in the @trusted function. You can assume that @system variables never were modified directly by @safe functions, and therefore, it's only necessary to review @trusted and @system functions to ensure the invariants hold.

Given the theory that most code is @safe and should be marked or inferred that way, you can therefore vastly reduce the amount of code that needs review for memory safety.

-Steve

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.

On Wednesday, 3 March 2021 at 12:54:53 UTC, Dukc wrote:
> 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":
>>>>>
>>>>> [...]

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

Yes, but not allowed in @safe code. My point is that @safe can still do:

auto arr = new int[7];
auto oops = arr[3_000_000];

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