This is the feedback thread for the second round of Community Review of DIP 1035, "@system Variables".

===================================
**THIS IS NOT A DISCUSSION THREAD**

Posts in this thread must adhere to the feedback thread rules outlined in the Reviewer Guidelines (and listed at the bottom of this post).

https://github.com/dlang/DIPs/blob/master/docs/guidelines-reviewers.md

That document also provides guidelines on contributing feedback to a DIP review. Please read it before posting here. If you would like to discuss this DIP, please do so in the discussion thread:

https://forum.dlang.org/post/flwbqmpcwenplqdofoih@forum.dlang.org
==================================

You can find DIP 1035 here:

https://github.com/dlang/DIPs/blob/c39f6ac62210e0604dcee99b0092c1930839f93a/DIPs/DIP1035.md

The review period will end at 11:59 PM ET on March 11, or when I make a post declaring it complete. Feedback posted to this thread after that point may be ignored.

At the end of this review round, the DIP will be moved into the Post-Community Round 2 state. Significant revisions resulting from this review round may cause the DIP manager to require another round of Community Review, otherwise the DIP will be queued for the Final Review.

==================================
Posts in this thread that do not adhere to the following rules will be deleted at the DIP author's discretion:

* All posts must be a direct reply to the DIP manager's initial post, with only two exceptions:

    - Any commenter may reply to their own posts to retract feedback contained in the original post

    - The DIP author may (and is encouraged to) reply to any feedback solely to acknowledge the feedback with agreement or disagreement (preferably with supporting reasons in the latter case)

* Feedback must be actionable, i.e., there must be some action the DIP author can choose to take in response to the feedback, such as changing details, adding new information, or even retracting the proposal.

* Feedback related to the merits of the proposal rather than to the contents of the DIP (e.g., "I'm against this DIP.") is allowed in Community Review (not Final Review), but must be backed by supporting arguments (e.g., "I'm against this DIP because..."). The supporting arguments must be reasonable. Obviously frivolous arguments waste everyone's time.

* Feedback should be clear and concise, preferably listed as bullet points (those who take the time to do an in-depth review and provide feedback in the form of answers to the questions in the documentation linked above will receive much gratitude). Information irrelevant to the DIP or which is not provided in service of clarifying the feedback is unwelcome.

On Thursday, 25 February 2021 at 09:23:35 UTC, Mike Parker wrote:
> This is the feedback thread for the second round of Community Review of DIP 1035, "@system Variables".

The rationale and description sections disagree on behaviour of `extern` global variables of unsafe type. Rationale says the compiler should disallow it in @safe code "since it's initial value is unknown", yet an example in description says:
```
extern int* x0;                   // @safe by default
```

I see problems in this rule: "An exception to the above rules <about variable @safe inference> is made on unsafe types when the compiler knows the resulting value is safe". With global or static variables, no problem. But when initializing a local variable, this may result in implementation-defined behaviour. It could be changed to something like: "Iff the initialization expression is required to be executed at compile by the spec, and the expression evaluates as a value the compiler knows to be safe, the variable is inferred as @safe".

Which leads to, what are the values compiler considers to be safe? I think I know roughly: every `.init` value, arrays and pointers pointing only to safe values, and structs/classes where all fields either:

1: are safe with safe type
2: are safe with unsafe type but safe value
3: are same as the fields static initialization value.

But this probably needs elaboration. It's self-explanatory with pointers and arrays, but not with user-defined unsafe types. It might be easier to just discard the exception about @safe inference: @safe initializers return @safe values, @system initializers return @system values, period.

All in all, I like this DIP.

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

On Monday, 1 March 2021 at 23:38:28 UTC, Dukc wrote:
> The rationale and description sections disagree on behaviour of
> `extern` global variables of unsafe type. Rationale says the compiler should disallow it in @safe code "since it's initial value is unknown", yet an example in description says:
> ```
> extern int* x0;                   // @safe by default
> ```

There is no disagreement, the rationale text you mention describes the situation before DIP 1035, while the description describes the situation after DIP 1035.

On Thursday, 25 February 2021 at 09:23:35 UTC, Mike Parker wrote:
> This is the feedback thread for the second round of Community Review of DIP 1035, "@system Variables".
>
> The review period will end at 11:59 PM ET on March 11, or when I make a post declaring it complete. Feedback posted to this thread after that point may be ignored.

This review round has ended and this Feedback Thread is now considered closed. Thanks to Dukc for providing feedback, and to the DIP authors for responding.

Assuming no major revisions are undertaken going forward, this DIP will enter the queue for a round of Final Review before I hand it off to Walter and Atila for Formal Assessment.