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.

> 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

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);
}

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!

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.

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"

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.