www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Feedback Thread: DIP 1035-- system Variables--Community Review Round 2

reply 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.
Feb 25
next sibling parent reply 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.
Mar 01
next sibling parent 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
Mar 01
prev sibling parent 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.
Mar 02
prev sibling parent 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.
Mar 12