On 2/27/21 4:13 PM, Paul Backus wrote:
> I understand from previous discussions that you have some less-rigorous ideas about what is "useful to programmers" and what is not, but I think this is an occasion where rigor is warranted.

This is going quite off topic, but I wanted to say this is absolutely not the driver for my point of view. It is not a matter of rigor but a matter of what are the expectations of what @safe should imply.

My point of view is that if the semantic meaning of a a @safe union between an int and a pointer currently is that the pointer isn't usable even in @trusted code (even though the compiler doesn't prevent you from doing it), then this is going to violate the expectations of the programmer (why would he write a union, when you can only use one of the members).

We should not only focus in our concept of @safe in proving the memory safety of the rules we come up with, but in coming up with rules that make sense in the context of utility to the programmer. We can make up whatever rules we want, and based on those rules, we can prove safety, but if the result is "you can do this, but it NEVER is usable", I think we can do better.

-Steve

On 2/27/2021 12:38 AM, Imperatorn wrote:
> On Saturday, 27 February 2021 at 05:59:23 UTC, Walter Bright wrote:
>>
>> https://issues.dlang.org/show_bug.cgi?id=21665
> 
> Would that be a compiler error or warning ignoring initialization if you tried to void init a struct having invariant?

error

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?

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

On Tuesday, 2 March 2021 at 02:46:58 UTC, Paul Backus on the feedback thread wrote:
> On Monday, 1 March 2021 at 23:38:28 UTC, Dukc wrote:
>> Which leads to, what are the values compiler considers to be safe?
>
> The answer to this question is is already part of the language spec:
>
> https://dlang.org/spec/function.html#safe-values

Yes, you can use that. But the dip needs to update that part of the spec, since what is going to be a safe struct instance / union instance / class ref value is changing. For instance, what the compiler will consider safe values for the `ShortString` struct provided in the example?

On Tuesday, 2 March 2021 at 11:48:09 UTC, Dukc wrote:
> On Tuesday, 2 March 2021 at 02:46:58 UTC, Paul Backus on the feedback thread wrote:
>> On Monday, 1 March 2021 at 23:38:28 UTC, Dukc wrote:
>>> Which leads to, what are the values compiler considers to be safe?
>>
>> The answer to this question is is already part of the language spec:
>>
>> https://dlang.org/spec/function.html#safe-values
>
> Yes, you can use that. But the dip needs to update that part of the spec, since what is going to be a safe struct instance / union instance / class ref value is changing. For instance, what the compiler will consider safe values for the `ShortString` struct provided in the example?

Good point. For user-defined unsafe types like ShortString, the compiler will have to assume that any value that can be obtained in @safe code is a safe value.

On Saturday, 27 February 2021 at 15:19:14 UTC, Kagamin wrote:
> On Saturday, 27 February 2021 at 13:32:24 UTC, Paul Backus wrote:
>> The compiler will still allow you to void-initialize/overlap/reinterpret-cast an Unsafe!size_t in @safe code, because it considers size_t to be a safe type.
>
> The wrapped value still won't be accessible to safe code.

You can access the wrapped value through a union in @safe code, and your @trusted code can't assume anything about your Unsafe!T, so it does not accomplish much.

On Tuesday, 2 March 2021 at 14:09:01 UTC, Paul Backus wrote:
> Good point. For user-defined unsafe types like ShortString, the compiler will have to assume that any value that can be obtained in @safe code is a safe value.

But what about determining `@safe`ty of value given by `@system` initializer? Is it just not attempted for user-defined types? Or is the rule "`.init` value is `@safe`, everything else is `@system`"? Or something more complicated?

On Tuesday, 2 March 2021 at 14:28:43 UTC, Dukc wrote:
> On Tuesday, 2 March 2021 at 14:09:01 UTC, Paul Backus wrote:
>> Good point. For user-defined unsafe types like ShortString, the compiler will have to assume that any value that can be obtained in @safe code is a safe value.
>
> But what about determining `@safe`ty of value given by `@system` initializer? Is it just not attempted for user-defined types? Or is the rule "`.init` value is `@safe`, everything else is `@system`"? Or something more complicated?

I think you may be confusing the safety of a *value* with the safety of a *variable*.

Consider the following example:

    @safe ShortString makeShortString(string source) { /* ... */ }

    auto s = makeShortString("hello");

The value of `makeShortString("hello")` is *assumed* to be a safe value, because `makeShortString` is a @safe function. Therefore, the variable `s` is *determined* to be a @safe variable, because its initializer is a safe value.

Regarding `.init`: because default initialization of any type is allowed in @safe code, the `.init` value of any user-defined type must be a safe value. This is true today, and it will still be true if DIP 1035 is accepted. The fact that the compiler currently does not enforce this is a bug. [1]

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

On Tuesday, 2 March 2021 at 14:57:04 UTC, Paul Backus wrote:
> I think you may be confusing the safety of a *value* with the safety of a *variable*.

No, I was thinking this piece:

> An exception to the above rules is made on unsafe types when
> the compiler knows the resulting value is safe.
> ```D
> int* getNull() pure @system {return null;}
> int* n = getNull(); // despite unsafe type with @system
> initialization expression, inferred as @safe
> ```

So the queastion is:

```D
ShortString getSString() pure @system {<...>}
//under what conditions, if any, is the initialization inferred as @safe here?
ShortString n = getSString();
```