On Tuesday, 2 March 2021 at 13:56:28 UTC, Dennis in the feedback thread wrote:
>
> There is no disagreement, the rationale text you mention describes the situation before DIP 1035, while the description describes the situation after DIP 1035.

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

On Tuesday, 2 March 2021 at 15:17:54 UTC, Dukc wrote:
> So the queastion is:
>
> ```D
> ShortString getSString() pure @system {<...>}
> //under what conditions, if any, is the initialization inferred as @safe here?
> ShortString n = getSString();
> ```

In this example, `n` will always be inferred as a @system variable.

On Tuesday, 2 March 2021 at 16:04:14 UTC, Paul Backus wrote:
> On Tuesday, 2 March 2021 at 15:17:54 UTC, Dukc wrote:
>> So the queastion is:
>>
>> ```D
>> ShortString getSString() pure @system {<...>}
>> //under what conditions, if any, is the initialization inferred as @safe here?
>> ShortString n = getSString();
>> ```
>
> In this example, `n` will always be inferred as a @system variable.

Fair enough. Remember to mention that in the DIP - either at the place I just quoted or at the changes you propose to what is considered a safe value.

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":

I don't have time to dig into this right now, and the current @system/@safe distinction is in need of being replaced by «something».

But, the problem with adding more stuff to this aspect of the type system is that the language is becoming increasingly convoluted.

At some point local improvements no longer improve the whole... and a redesign is the only reasonable approach.

On Tuesday, 2 March 2021 at 16:30:59 UTC, Ola Fosheim Grøstad wrote:
> But, the problem with adding more stuff to this aspect of the type system is that the language is becoming increasingly convoluted.
>
> At some point local improvements no longer improve the whole... and a redesign is the only reasonable approach.

This particular improvement should not add that much complexity cost, as it is rather a completion of a previously added feature (@safe/@trusted/@system) than a new feature. If you know how memory safety of D works right now, you can probably figure out what `@system extern int;` does. And if you have `struct mySlice{int* ptr; @system size_t length;}` it is not probably going to surprise you that you can't directly write to either of the slice variables.

On Tuesday, 2 March 2021 at 19:32:38 UTC, Dukc wrote:
> This particular improvement should not add that much complexity cost, as it is rather a completion of a previously added feature (@safe/@trusted/@system) than a new feature.

Maybe, but one could probably say that for every individual feature. E.g. the various "@safe" parameter mechanisms, scope, @live. It adds up.

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

On 02.03.21 21:46, Atila Neves wrote:
> Pointer types *can* be unsafe, if the values came from @system code. 

Pointer *values* can be unsafe, if they come from @system code. A type that can have unsafe values is an unsafe type (so defined in the DIP). So pointer types are unsafe types.

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.

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.