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.

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

The Feedback Thread is here:

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

On Wednesday, 15 June 2022 at 09:21:12 UTC, Mike Parker 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);

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.

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

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

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

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

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

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

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

// 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#.

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

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:

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

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

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

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

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

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

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

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

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.

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:

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.