www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Feedback Thread: DIP 1033--Implicit Conversion of Expressions to

reply Mike Parker <aldacron gmail.com> writes:
This is the feedback thread for the first round of Community 
Review of DIP 1033, "Implicit Conversion of Expressions to 
Delegates".

===================================
**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/ecxdylguqkhtmdomlzhq forum.dlang.org

==================================

You can find DIP 1033 here:

https://github.com/dlang/DIPs/blob/7b61411cb6cf8db05d9b8e1df5d2d9bae53a5f1e/DIPs/DIP1033.md

The review period will end at 11:59 PM ET on May 6, 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 1 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 
this document will receive much gratitude). Information 
irrelevant to the DIP or is not provided in service of clarifying 
the feedback is unwelcome.
Apr 22 2020
next sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
 Function Pointers
 Implicit conversion of expressions to function lambdas is not done. There
doesn't seem much point to it, as there will be no arguments to the function
lambda, meaning the expression can only consist of globals.


Why does it have to consist only of globals?

int delegate() = 3;

doesn't use any globals. Why shouldn't this work?

int function() = 3;

Also typo here:


 Currently, arguments to lazy paraeters 


parameters

-Steve
Apr 22 2020
parent Walter Bright <newshound2 digitalmars.com> writes:
On 4/22/2020 5:14 AM, Steven Schveighoffer wrote:

 Function Pointers
 Implicit conversion of expressions to function lambdas is not done. There 
 doesn't seem much point to it, as there will be no arguments to the function 
 lambda, meaning the expression can only consist of globals.


 
 Why does it have to consist only of globals?
 
 int delegate() = 3;
 
 doesn't use any globals. Why shouldn't this work?
 
 int function() = 3;


Because it seems kinda pointless to support function pointers only with
constants.

While it is not impossible to support function pointers with this, I can't
think 
of a compelling use case.



 Also typo here:
 

 Currently, arguments to lazy paraeters 


 
 parameters


Sorry. I meant "paræters"
Apr 22 2020
prev sibling next sibling parent reply aliak <something something.com> writes:
On Wednesday, 22 April 2020 at 07:43:56 UTC, Mike Parker wrote:

 This is the feedback thread for the first round of Community 
 Review of DIP 1033, "Implicit Conversion of Expressions to 
 Delegates".

 ===================================
 **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/ecxdylguqkhtmdomlzhq forum.dlang.org

 ==================================

 You can find DIP 1033 here:

 https://github.com/dlang/DIPs/blob/7b61411cb6cf8db05d9b8e1df5d2d9bae53a5f1e/DIPs/DIP1033.md

 The review period will end at 11:59 PM ET on May 6, 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 1 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 
 this document will receive much gratitude). Information 
 irrelevant to the DIP or is not provided in service of 
 clarifying the feedback is unwelcome.


The rationale for this entire DIP seems to center around the 
inadequacies of lazy. Some feedback on them:

1. it stands out as an oddity
   Why is it an oddity? Is it an oddity in the sense of point 4? 
Or? Lazy is quite a common concept in a lot of languages and also 
very useful in terms of functionality and documentation of intent.

2. being an oddity means it is hard to reason about, especially 
with the proliferation of parameter attributes
   Being an oddity implies it's hard to reason about?? I'm not 
sure I get this link?

3. it is underdocumented
   Is this really a valid reason to do something? The fix is very 
simple.

5. it is rarely used, so likely has many undetected problems
   Again is this valid? extern(C++) is used less than lazy 
according to searches on github.

6. that it works like a delegate has largely gone unrecognized
   Huh?

It sounds like point 4 is the real reason behind this? And if it 
is, then maybe the difficulties there can be expanded upon?

On breaking changes, the section on overloading shows an example 
on something that would break but the breaking changes section 
says nothing would break:

// Today ok but will be a compiler error after this?
void f(long) {}
void f(long delegate()) {}

void boink()
{
     int i;
     f(i);
}
Apr 22 2020
parent aliak <something something.com> writes:
On Wednesday, 22 April 2020 at 12:31:47 UTC, aliak wrote:


 6. that it works like a delegate has largely gone unrecognized
   Huh?


Sorry, that comment was not supposed to be there!
Apr 22 2020
prev sibling parent reply dayllenger <dayllenger protonmail.com> writes:
On Wednesday, 22 April 2020 at 07:43:56 UTC, Mike Parker wrote:

 This is the feedback thread for the first round of Community 
 Review of DIP 1033, "Implicit Conversion of Expressions to 
 Delegates".

 [...]


One point to add: lazy variadic parameters 
(https://dlang.org/spec/function.html#lazy_variadic_functions) 
already work exactly as stated in the DIP. `lazy` is not 
expressive enough to cover that case.
Apr 22 2020
parent Walter Bright <newshound2 digitalmars.com> writes:
On 4/22/2020 9:19 AM, dayllenger wrote:

 On Wednesday, 22 April 2020 at 07:43:56 UTC, Mike Parker wrote:

 This is the feedback thread for the first round of Community Review of DIP 
 1033, "Implicit Conversion of Expressions to Delegates".

 [...]


 
 One point to add: lazy variadic parameters 
 (https://dlang.org/spec/function.html#lazy_variadic_functions) already work 
 exactly as stated in the DIP. `lazy` is not expressive enough to cover that
case.


Good catch, I had overlooked that.
Apr 22 2020