• Mike Parker (50/50) Feb 25 2021 This is the feedback thread for the second round of Community
• Dukc (30/32) Mar 01 2021 The rationale and description sections disagree on behaviour of
• Paul Backus (4/6) Mar 01 2021 The answer to this question is is already part of the language
• Dennis (4/11) Mar 02 2021 There is no disagreement, the rationale text you mention
• Mike Parker (7/12) Mar 12 2021 This review round has ended and this Feedback Thread is now

Mike Parker <aldacron gmail.com> writes:

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.

Dukc <ajieskola gmail.com> writes:

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.

Paul Backus <snarwin gmail.com> writes:

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

Dennis <dkorpel gmail.com> writes:

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.

Mike Parker <aldacron gmail.com> writes:

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.