Jump to page: 1 25  
Page
Thread overview
Discussion Thread: DIP 1043--Shortened Method Syntax--Final Review
Jun 15
bauss
Jun 15
Basile B.
Jun 15
bauss
Jun 16
bauss
Jun 17
harakim
Jun 17
ag0aep6g
Jun 28
welkam
Jun 28
welkam
Jun 28
bauss
Jun 29
bauss
Jun 29
zjh
Jun 29
bauss
Jul 01
welkam
Jul 01
welkam
Jun 28
welkam
Jun 28
zjh
Jun 29
zjh
Jun 28
forkit
Jun 28
Dukc
June 15

This is the discussion thread for the Final Review of DIP 1043, "Shortened Method Syntax":

https://github.com/dlang/DIPs/blob/2c2f6c33f5761236266a96bd268c62a06323a5e8/DIPs/DIP1043.md

The review period will end at 11:59 PM ET on June 29, or when I make a post declaring it complete. Discussion in this thread may continue beyond that point.

Here in the discussion thread, you are free to discuss anything and everything related to the DIP. Express your support or opposition, debate alternatives, argue the merits, etc.

However, if you have any specific feedback on how to improve the proposal itself, then please post it in the feedback thread. The feedback thread will be the source for the review summary I write at the end of this review round. I will post a link to that thread immediately following this post. Just be sure to read and understand the Reviewer Guidelines before posting there:

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

And my blog post on the difference between the Discussion and Feedback threads:

https://dlang.org/blog/2020/01/26/dip-reviews-discussion-vs-feedback/

Please stay on topic here. I will delete posts that are completely off-topic.

June 15

On Wednesday, 15 June 2022 at 09:21:12 UTC, Mike Parker wrote:

>

However, if you have any specific feedback on how to improve the proposal itself, then please post it in the feedback thread. The feedback thread will be the source for the review summary I write at the end of this review round. I will post a link to that thread immediately following this post.

The Feedback Thread is here:

https://forum.dlang.org/post/xxfdyxrnskdxzvdigwld@forum.dlang.org

June 15

On Wednesday, 15 June 2022 at 09:21:12 UTC, Mike Parker wrote:

>

This is the discussion thread for the Final Review of DIP 1043, "Shortened Method Syntax":

https://github.com/dlang/DIPs/blob/2c2f6c33f5761236266a96bd268c62a06323a5e8/DIPs/DIP1043.md

The review period will end at 11:59 PM ET on June 29, or when I make a post declaring it complete. Discussion in this thread may continue beyond that point.

Here in the discussion thread, you are free to discuss anything and everything related to the DIP. Express your support or opposition, debate alternatives, argue the merits, etc.

However, if you have any specific feedback on how to improve the proposal itself, then please post it in the feedback thread. The feedback thread will be the source for the review summary I write at the end of this review round. I will post a link to that thread immediately following this post. Just be sure to read and understand the Reviewer Guidelines before posting there:

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

And my blog post on the difference between the Discussion and Feedback threads:

https://dlang.org/blog/2020/01/26/dip-reviews-discussion-vs-feedback/

Please stay on topic here. I will delete posts that are completely off-topic.

I'm still under the belief that it shouldn't just be AssignExpression, because you should be able to use it to call another function that has no return type.

Ex.

void a(int x, int y) { ... }

void b(int x) => a(x, 100);

As the DIP uses C# as a prime example of it, because the above will work in C#.

It's very useful for things like this:

@property int x() => _x;
@property void x(int value) => _x = value;

C# equivalent:

int X { get => _x;  set => _x = value; }

I might not understand something from the DIP, but I don't think it's clear whether that is supported or not and AssignExpression tells me that it's not, but maybe I don't understand what AssignExpression exactly entails.

June 15

On Wednesday, 15 June 2022 at 09:35:37 UTC, bauss wrote:

>

On Wednesday, 15 June 2022 at 09:21:12 UTC, Mike Parker wrote:

>

This is the discussion thread for the Final Review of DIP 1043, "Shortened Method Syntax":

https://github.com/dlang/DIPs/blob/2c2f6c33f5761236266a96bd268c62a06323a5e8/DIPs/DIP1043.md

The review period will end at 11:59 PM ET on June 29, or when I make a post declaring it complete. Discussion in this thread may continue beyond that point.

Here in the discussion thread, you are free to discuss anything and everything related to the DIP. Express your support or opposition, debate alternatives, argue the merits, etc.

However, if you have any specific feedback on how to improve the proposal itself, then please post it in the feedback thread. The feedback thread will be the source for the review summary I write at the end of this review round. I will post a link to that thread immediately following this post. Just be sure to read and understand the Reviewer Guidelines before posting there:

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

And my blog post on the difference between the Discussion and Feedback threads:

https://dlang.org/blog/2020/01/26/dip-reviews-discussion-vs-feedback/

Please stay on topic here. I will delete posts that are completely off-topic.

I'm still under the belief that it shouldn't just be AssignExpression, because you should be able to use it to call another function that has no return type.

Ex.

void a(int x, int y) { ... }

void b(int x) => a(x, 100);

As the DIP uses C# as a prime example of it, because the above will work in C#.

It's very useful for things like this:

@property int x() => _x;
@property void x(int value) => _x = value;

C# equivalent:

int X { get => _x;  set => _x = value; }

I might not understand something from the DIP, but I don't think it's clear whether that is supported or not and AssignExpression tells me that it's not, but maybe I don't understand what AssignExpression exactly entails.

AssignExp does not mean that there's an assignment, it just parse everything from that but can returns a simple primary, e.g IntegerExp.

Otherwise the concern about void is valid but I think that this can be solved easily during the semantic passes: if we're in a func and if we're in a shortened func then if this func is void then inserts a void cast to the expression. No technical issue there, as long as there's a flag that makes shortened funcs recognizable after lowering.

// void f() => 0;
void f() {return cast(void)0;}
June 15

On Wednesday, 15 June 2022 at 11:45:14 UTC, Basile B. wrote:

>

Otherwise the concern about void is valid but I think that this can be solved easily during the semantic passes: if we're in a func and if we're in a shortened func then if this func is void then inserts a void cast to the expression. No technical issue there, as long as there's a flag that makes shortened funcs recognizable after lowering.

// void f() => 0;
void f() {return cast(void)0;}

Yes, to be honest; I don't really care about how it's solved, just that it's possible to write code equivalent to what I can in C#.

June 15

On Wednesday, 15 June 2022 at 09:35:37 UTC, bauss wrote:

>

I'm still under the belief that it shouldn't just be AssignExpression, because you should be able to use it to call another function that has no return type.

Ex.

void a(int x, int y) { ... }

void b(int x) => a(x, 100);

This already works--both for the new syntax, and for the existing arrow-lambda syntax, and even for functions with an explicit return statement:

void a(int x, int y) { /* ... */ }
void b(int x) => a(x, 100);
void function(int) c = x => a(x, 100);
void d(int x) { return a(x, 100); }

There is no need to specify this in the DIP because it is already documented in the language spec, under the description of return statements:

>

An Expression of type void is allowed if the function specifies a void return type. The Expression will be evaluated, but nothing will be returned.

https://dlang.org/spec/statement.html#return-statement

June 15

On 6/15/22 5:35 AM, bauss wrote:

>

On Wednesday, 15 June 2022 at 09:21:12 UTC, Mike Parker wrote:

>

This is the discussion thread for the Final Review of DIP 1043, "Shortened Method Syntax":

https://github.com/dlang/DIPs/blob/2c2f6c33f5761236266a96bd268c62a06323a5e8/DIPs/DIP1043.md

The review period will end at 11:59 PM ET on June 29, or when I make a post declaring it complete. Discussion in this thread may continue beyond that point.

Here in the discussion thread, you are free to discuss anything and everything related to the DIP. Express your support or opposition, debate alternatives, argue the merits, etc.

However, if you have any specific feedback on how to improve the proposal itself, then please post it in the feedback thread. The feedback thread will be the source for the review summary I write at the end of this review round. I will post a link to that thread immediately following this post. Just be sure to read and understand the Reviewer Guidelines before posting there:

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

And my blog post on the difference between the Discussion and Feedback threads:

https://dlang.org/blog/2020/01/26/dip-reviews-discussion-vs-feedback/

Please stay on topic here. I will delete posts that are completely off-topic.

I'm still under the belief that it shouldn't just be AssignExpression, because you should be able to use it to call another function that has no return type.

Ex.

void a(int x, int y) { ... }

void b(int x) => a(x, 100);

As the DIP uses C# as a prime example of it, because the above will work in C#.

It's very useful for things like this:

@property int x() => _x;
@property void x(int value) => _x = value;

C# equivalent:

int X { get => _x;  set => _x = value; }

I might not understand something from the DIP, but I don't think it's clear whether that is supported or not and AssignExpression tells me that it's not, but maybe I don't understand what AssignExpression exactly entails.

AssignExpression is correct.

in the grammar, a return statement is return Expression.

An Expression is CommaExpression, which is:

AssignExpression
Expression , AssignExpression

(https://dlang.org/spec/expression.html#CommaExpression)

So unless you need comma expressions (which are technically illegal as a return expression), AssignExpression is equivalent. This basically is trimming the "fat" of the comma expression from where it's already illegal.

Note that this works today:

void foo() {}
void bar() { return foo(); }

So I wouldn't expect shortened methods to work any different. Indeed with the preview switch they do:

void baz() => foo(); // compiles

-Steve

June 15
On Wednesday, 15 June 2022 at 13:40:20 UTC, Paul Backus wrote:
> This already works--both for the new syntax, and for the existing arrow-lambda syntax, and even for functions with an explicit `return` statement:

Indeed, though if one of them doesn't return void:

int a() => 0;

void b() => a();

This will "Error: cannot return non-void from `void` function"

You can `void b() => cast(void) a();` to explicitly discard the return value and then it builds.

I'm perfectly fine with that the way it is, just mentioning for factual completeness.
June 15

On Wednesday, 15 June 2022 at 09:21:12 UTC, Mike Parker wrote:

>

Express your support

I'm rarely enthusiastic about new syntax for things, however in this case I find the DIP fitting with the langage and desirable. Especially since I kinda follow the D-style (https://dlang.org/dstyle.html#phobos_brackets) this can win valuable screen estate.

June 16

On Wednesday, 15 June 2022 at 13:40:20 UTC, Paul Backus wrote:

>

...

On Wednesday, 15 June 2022 at 13:49:04 UTC, Steven Schveighoffer wrote:

>

...

Thank you, like I said I wasn't sure if that was supported by the name of AssignExpression and whether it would work, but seems like everything is good.

So from my point of view then everything is okay.

On Wednesday, 15 June 2022 at 13:50:28 UTC, Adam D Ruppe wrote:

>

On Wednesday, 15 June 2022 at 13:40:20 UTC, Paul Backus wrote:

>

This already works--both for the new syntax, and for the existing arrow-lambda syntax, and even for functions with an explicit return statement:

Indeed, though if one of them doesn't return void:

int a() => 0;

void b() => a();

This will "Error: cannot return non-void from void function"

You can void b() => cast(void) a(); to explicitly discard the return value and then it builds.

I'm perfectly fine with that the way it is, just mentioning for factual completeness.

I'm perfectly fine with this not working, because I think that could lead to subtle bugs.

I'm a strong believer of that if a function returns a value then you must use that value and should only discard it if absolutely necessary or if you're debugging.

« First   ‹ Prev
1 2 3 4 5