www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Discussion Thread: DIP 1043--Shortened Method Syntax--Final Review

reply Mike Parker <aldacron gmail.com> writes:
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.
Jun 15
next sibling parent Mike Parker <aldacron gmail.com> writes:
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
Jun 15
prev sibling next sibling parent reply bauss <jj_1337 live.dk> writes:
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. ```d void a(int x, int y) { ... } void b(int x) => a(x, 100); ``` It's very useful for things like this: ```d property int x() => _x; property void x(int value) => _x = value; ``` ```d 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.
Jun 15
next sibling parent reply Basile B. <b2.temp gmx.com> writes:
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. ```d void a(int x, int y) { ... } void b(int x) => a(x, 100); ``` It's very useful for things like this: ```d property int x() => _x; property void x(int value) => _x = value; ``` ```d 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. ```d // void f() => 0; void f() {return cast(void)0;} ```
Jun 15
parent bauss <jj_1337 live.dk> writes:
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.

 ```d
 // 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
Jun 15
prev sibling next sibling parent reply Paul Backus <snarwin gmail.com> writes:
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.

 ```d
 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: ```d 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
Jun 15
next sibling parent Adam D Ruppe <destructionator gmail.com> writes:
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.
Jun 15
prev sibling next sibling parent reply bauss <jj_1337 live.dk> writes:
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.
Jun 15
parent Quirin Schroll <qs.il.paperinik gmail.com> writes:
On Thursday, 16 June 2022 at 06:54:39 UTC, bauss wrote:
 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.
This has never been true. Most functions fall exactly into one of these two categories: * Returns void. * The return value is the purpose. A rather small fraction of functions returns a value one is conditionally interested in. An example is C’s `printf` or .NET’s [MessageBox.Show](https://docs.microsoft.com/en-us/dotnet/api/system.windows.fo ms.messagebox.show) where *sometimes* you’re interested in the result and sometimes it is clear from the code what the result will be. However, one almost never confuses the times when the result is relevant with those when they’re not. A minute fraction of functions returns a value that is not the (only or primary) purpose of the function, e.g. an error code, but ignoring it is wrong in almost all cases. Those functions should have a [` mustuse`](https://dlang.org/spec/attribute.html#mustuse-attribute) annotated return type. Implicit discard of ` mustuse` through void returning `=>` without `cast(void)` should be an error.
Jul 19
prev sibling parent reply harakim <harakim gmail.com> writes:
On Wednesday, 15 June 2022 at 13:40:20 UTC, Paul Backus wrote:
 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.

 ```d
 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: ```d 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
Oh wow! Doing if () { writeln(); return; } has been a pet peeve of mine almost since I started programming. I never knew you could do if() return writeln() in D. That made my day. Thanks!
Jun 17
parent Quirin Schroll <qs.il.paperinik gmail.com> writes:
On Friday, 17 June 2022 at 22:11:38 UTC, harakim wrote:
 Oh wow! Doing `if (…) { writeln(); return; }` has been a pet 
 peeve of mine almost since I started programming. I never knew 
 you could do `if (…) return writeln()` in D. That made my day. 
 Thanks!
Only because you *can* does not imply you *should.*
Jul 19
prev sibling parent Steven Schveighoffer <schveiguy gmail.com> writes:
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/2c2f6c33f5761236266a96bd268c62a06323
5e8/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. ```d void a(int x, int y) { ... } void b(int x) => a(x, 100); ``` It's very useful for things like this: ```d property int x() => _x; property void x(int value) => _x = value; ``` ```d 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](https://dlang.org/spec/statement.html#return-statement) is `return Expression`. An [Expression](https://dlang.org/spec/expression.html#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: ```d void foo() {} void bar() { return foo(); } ``` So I wouldn't expect shortened methods to work any different. Indeed with the preview switch they do: ```d void baz() => foo(); // compiles ``` -Steve
Jun 15
prev sibling next sibling parent Guillaume Piolat <first.last gmail.com> writes:
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.
Jun 15
prev sibling next sibling parent reply Salih Dincer <salihdb hotmail.com> writes:
On Wednesday, 15 June 2022 at 09:21:58 UTC, Mike Parker wrote:

 [..] in the Reviewer Guidelines (and listed at the bottom of 
 this post).

 https://github.com/dlang/DIPs/blob/master/docs/guidelines-reviewers.md
I don't need to write at length. The only thing I always have difficulty with is writing a class constructor! ```d struct Color {} class Point { Color rgba; int x, y; bool hidden; this(Color r, int x, int y, bool h) { this.rgba = r; this.x = x; this.y = y; this.hidden = h; } } ``` Well if it was shorter we would compile it right away, just like a struct. For example: ```d // ... this( all); } ``` SDB 79
Jun 16
parent reply Paul Backus <snarwin gmail.com> writes:
On Thursday, 16 June 2022 at 18:15:52 UTC, Salih Dincer wrote:
 I don't need to write at length. The only thing I always have 
 difficulty with is writing a class constructor!

 ```d
 struct Color {}
 class Point {
   Color rgba;
   int x, y;
   bool hidden;

   this(Color r, int x, int y, bool h) {
     this.rgba = r;
     this.x = x;
     this.y = y;
     this.hidden = h;
   }
 }
 ```
 Well if it was shorter we would compile it right away, just 
 like a struct. For example:

 ```d
   // ...
   this( all);
 }
 ```
 SDB 79
```d enum defaultClassConstructor = q{ this(typeof(this.tupleof) params) { static foreach (i; 0 .. this.tupleof.length) { this.tupleof[i] = params[i]; } } }; struct Color {} class Point { Color rgba; int x, y; bool hidden; mixin(defaultClassConstructor); } void main() { Point p = new Point(Color(), 123, 456, false); assert(p.x == 123); assert(p.y == 456); assert(p.hidden == false); } ```
Jun 16
next sibling parent ag0aep6g <anonymous example.com> writes:
On 16.06.22 20:56, Paul Backus wrote:
      this(typeof(this.tupleof) params)
      {
          static foreach (i; 0 .. this.tupleof.length)
          {
              this.tupleof[i] = params[i];
          }
      }
You don't need the loop: this(typeof(this.tupleof) params) { this.tupleof = params; /* works */ }
Jun 16
prev sibling next sibling parent reply Nick Treleaven <nick geany.org> writes:
On Thursday, 16 June 2022 at 18:56:57 UTC, Paul Backus wrote:
 class Point
 {
     Color rgba;
     int x, y;
     bool hidden;

     mixin(defaultClassConstructor);
 }
It could also allow skipping some fields and support custom initialization of those fields using a function literal: ```d // declare `this(rgba, x, y)`, no `hidden` parameter mixin defaultClassCtor!("!hidden", { hidden = ...; }); ``` The function literal would run after the default assignments. Alternatively the parameters to use could be listed: ```d // declare `this(rgba, x, y)`, no `hidden` parameter mixin defaultClassCtor!(q{rgba, x, y}, { hidden = ...; }); ``` It could skip private fields by default, or include them with a flag: ```d // include private fields mixin defaultClassCtor!(Yes.privateFields); ``` It could support default arguments: ```d mixin defaultClassCtor!(q{x = 0, y = 10}); ``` And ddoc works for a documented template mixin declaration containing a documented constructor.
Jun 17
parent Paul Backus <snarwin gmail.com> writes:
On Friday, 17 June 2022 at 13:17:37 UTC, Nick Treleaven wrote:
 It could also allow skipping some fields and support custom 
 initialization of those fields using a function literal:
[...]
 And ddoc works for a documented template mixin declaration 
 containing a documented constructor.
Unfortunately you pretty much have to use a string mixin, to avoid [issue 3332][1]. For a more sophisticated implementation, [`GenerateThis`][2] from the [`boilerplate` package][3] is probably the way to go. [1]: https://issues.dlang.org/show_bug.cgi?id=3332 [2]: https://boilerplate.dpldocs.info/v1.7.7/boilerplate.constructor.GenerateThis.html [3]: https://code.dlang.org/packages/boilerplate
Jun 17
prev sibling parent reply Salih Dincer <salihdb hotmail.com> writes:
On Thursday, 16 June 2022 at 18:56:57 UTC, Paul Backus wrote:
 ```d
 enum defaultClassConstructor = q{
  this(typeof(this.tupleof) params) {
    static foreach (i; 0..this.tupleof.length)
      this.tupleof[i] = params[i];
 };
 ```
Thanks, it looks very short... SDB 79
Jun 17
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 6/17/22 19:08, Salih Dincer wrote:
 On Thursday, 16 June 2022 at 18:56:57 UTC, Paul Backus wrote:
 ```d
 enum defaultClassConstructor = q{
  this(typeof(this.tupleof) params) {
    static foreach (i; 0..this.tupleof.length)
      this.tupleof[i] = params[i];
 };
 ```
Thanks, it looks very short... SDB 79
```d enum defaultClassConstructor = q{ this(typeof(this.tupleof) params){ this.tupleof = params; } }; ```
Jun 17
prev sibling next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 6/15/22 11:21, Mike Parker wrote:
 Express your support
I support this DIP. Named functions should be at as easy to write as function literals. Apparently I have brought this up back in 2011 (IIRC this was shortly after the feature was added for function literals): https://issues.dlang.org/show_bug.cgi?id=7176
Jun 17
prev sibling next sibling parent Nick Treleaven <nick geany.org> writes:
On Wednesday, 15 June 2022 at 09:21:12 UTC, Mike Parker wrote:
 Here in the discussion thread, you are free to discuss anything 
 and everything related to the DIP. Express your support or
I strongly support this DIP as it makes function definition syntax more consistent with lambdas. It also avoids brace nesting which is visually noisy. The lowering is easy to understand with no special cases. The updated DIP is well written and answered the points raised from the initial review.
Jun 17
prev sibling next sibling parent reply welkam <wwwelkam gmail.com> writes:
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.
Burn this dip with fire. There were a lot of talks about readability here but from what I can tell people mean two different things when they use the word readability. One is easy on the eyes, pleasant to look at. The other meaning would be its easy to understand what the code is just by glancing at it. Proposed changes would succeed in making code less noisy and easier on the eyes but it will also harm scanability of the code. Programmers rely on visual patters to understand the code. That's why consistent code look is so important. That's why coding standards are enforced. But its not important only within a project but also across ecosystem. D doesn't have AST macros not because they are not useful but because each project would look like it was written in a different language. Not in extreme case but I hope you got the point. Go language is the way it is for valid reasons. Don't dismiss them easily.
Jun 28
next sibling parent reply max haughton <maxhaton gmail.com> writes:
On Tuesday, 28 June 2022 at 10:37:08 UTC, welkam 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.
Burn this dip with fire. There were a lot of talks about readability here but from what I can tell people mean two different things when they use the word readability. One is easy on the eyes, pleasant to look at. The other meaning would be its easy to understand what the code is just by glancing at it. Proposed changes would succeed in making code less noisy and easier on the eyes but it will also harm scanability of the code. Programmers rely on visual patters to understand the code. That's why consistent code look is so important. That's why coding standards are enforced. But its not important only within a project but also across ecosystem. D doesn't have AST macros not because they are not useful but because each project would look like it was written in a different language. Not in extreme case but I hope you got the point. Go language is the way it is for valid reasons. Don't dismiss them easily.
Part of the rationale for this, other than consistency, is that (in my eyes at least) it requires *less* pattern recognition. Although I gave some hand-wavey discussion of keypresses and typing in the DIP, the key reason for having this in my view is -other than syntactic unification - that it's use allows the declaration of a function to be reduced to only the part that actually does work. Personally, the moment a program's code looks (i.e. my eyes glaze over) to have patterns I am fighting a losing battle. It's just noise to me. At the granularity of a function declaration I do not feel I rely on patterns - in fact, this DIP is mainly aimed at methods within the definitions of classes and structs: Any redundant syntax in this context actively hinders reading of code by virtue of there being limited space on one's screen. It may also be of note that this pattern is already widespread in idiomatic D code in the form of shortened function literal expressions. I have no response to the point about AST macros, it doesn't seem particularly relevant to the DIP.
Jun 28
parent reply welkam <wwwelkam gmail.com> writes:
On Tuesday, 28 June 2022 at 11:08:50 UTC, max haughton wrote:
 It may also be of note that this pattern is already widespread 
 in idiomatic D code in the form of shortened function literal 
 expressions.
Thats a strange way to say that this is similar to lambda syntax/ its the same pattern.
 I have no response to the point about AST macros, it doesn't 
 seem particularly relevant to the DIP.
What AST macros do is they create dialects of the language. Each project that uses them have different "feel" to them and even if you are an expert in that language you would still need to learn the dialect of the project before you could understand what the code does. This DIP "pushes" us in the same direction but with smaller "force". Go was designed by a very senior programmers to be simple for a reason. They wanted to prevent junior programmers from writing "clever" code. They made the language the way it is so all code could be easily understood by anyone. Simplicity has a value. Many very senior developers choose to start new project in C because it is simple. In programming languages there are negative aspects of allowing to do the same thing in different ways.
Jun 28
next sibling parent max haughton <maxhaton gmail.com> writes:
On Tuesday, 28 June 2022 at 13:17:44 UTC, welkam wrote:
 On Tuesday, 28 June 2022 at 11:08:50 UTC, max haughton wrote:
 [...]
Thats a strange way to say that this is similar to lambda syntax/ its the same pattern. [...]
Function syntax and AST macros are too vastly different types of weapons.
 Very many senior developers
Do they now? I've never seen any. If senior means senile perhaps. Simplicity is fine, C is not a simple language.
Jun 28
prev sibling parent Steven Schveighoffer <schveiguy gmail.com> writes:
On 6/28/22 9:17 AM, welkam wrote:
 Go was designed by a very senior programmers to be simple for a reason. 
 They wanted to prevent junior programmers from writing "clever" code. 
 They made the language the way it is so all code could be easily 
 understood by anyone. Simplicity has a value.
 
 Many very senior developers choose to start new project in C because it 
 is simple.
These languages still exist, and are fine choices for you to make! -Steve
Jun 28
prev sibling next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 28 June 2022 at 10:37:08 UTC, welkam wrote:
 Programmers rely on visual patters to understand the code. 
 That's why consistent code look is so important.
It isn't ideal to allow this for methods as they are «messages» to objects and not lambdas. I did use it in Dart, because it was shorter, but it does make classes look more messy. It makes more sense for pure free standing functions as they can be viewed as named lambdas. I think "=>" should imply `pure` then it would make some sense to have two notations for the same thing.
Jun 28
parent reply bauss <jj_1337 live.dk> writes:
On Tuesday, 28 June 2022 at 12:01:37 UTC, Ola Fosheim Grøstad 
wrote:
 On Tuesday, 28 June 2022 at 10:37:08 UTC, welkam wrote:
 Programmers rely on visual patters to understand the code. 
 That's why consistent code look is so important.
It isn't ideal to allow this for methods as they are «messages» to objects and not lambdas. I did use it in Dart, because it was shorter, but it does make classes look more messy. It makes more sense for pure free standing functions as they can be viewed as named lambdas. I think "=>" should imply `pure` then it would make some sense to have two notations for the same thing.
It makes a lot of sense for properties too, in classes as well.
Jun 28
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 28 June 2022 at 12:05:22 UTC, bauss wrote:
 It makes a lot of sense for properties too, in classes as well.
For pure getters perhaps. I still don't like the visuals in classes, but I don't have strong opinions about it either.
Jun 28
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 6/28/22 12:37, welkam 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/2c2f6c33f5761236266a96bd268c62a06323
5e8/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.
Burn this dip with fire. There were a lot of talks about readability here but from what I can tell people mean two different things when they use the word readability. One is easy on the eyes, pleasant to look at. The other meaning would be its easy to understand what the code is just by glancing at it. Proposed changes would succeed in making code less noisy and easier on the eyes but it will also harm scanability of the code.
The opposite is the case.
 Programmers rely on visual patters to understand the code.
This is just another pattern, a rather distinctive one and one that is mostly already in the language.
 Go language is the way it is for valid reasons. Don't dismiss them easily. 
Why not? I dislike Go for valid reasons.
Jun 28
next sibling parent reply bauss <jj_1337 live.dk> writes:
On Tuesday, 28 June 2022 at 16:32:46 UTC, Timon Gehr wrote:
 Go language is the way it is for valid reasons. Don't dismiss 
 them easily.
Why not? I dislike Go for valid reasons.
Most people do. Go is a terrible example for a good language. Go only has one advantage and that's Google backing.
Jun 28
parent reply zjh <fqbqrr 163.com> writes:
On Wednesday, 29 June 2022 at 05:54:49 UTC, bauss wrote:
 Go only has one advantage and that's Google backing.
`Google` hasn't let you suffer yet?
Jun 28
parent bauss <jj_1337 live.dk> writes:
On Wednesday, 29 June 2022 at 06:05:38 UTC, zjh wrote:
 On Wednesday, 29 June 2022 at 05:54:49 UTC, bauss wrote:
 Go only has one advantage and that's Google backing.
`Google` hasn't let you suffer yet?
Depends, many things have made me suffer, D has too.
Jun 29
prev sibling parent reply welkam <wwwelkam gmail.com> writes:
On Tuesday, 28 June 2022 at 16:32:46 UTC, Timon Gehr wrote:
 Go language is the way it is for valid reasons. Don't dismiss 
 them easily.
Why not? I dislike Go for valid reasons.
I dont like Go as a language as well but I can still recognize that simplicity and uniformity is a valuable thing. Now its crystal clear that I was unable to effectively communicate what I was thinking. The problem is that I dont know how else should I did it. Google has a problem that they constantly are hiring new programmers and those programmers write code in their own way. Code bases written this way are not optimal. Go being the way it is makes its so that it easier to teach the language and its easier to onboard new programmer onto the project. I'm not going to list the negative trade offs of Go`s design decisions as I believe its obvious for people in this forum. On the other hand the benefits of Go or C designs seem to be valued at 0. Discussions here revolved around question "do you want these benefits or not?" while it should have been "do you think the benefits are worth the tradeoffs?". Instead of talking about the best case scenario of one line functions in classes more time should have given to other possible uses and its effects on readability. ```d auto bar() => iota(1, 100) .map!(x => x + 1) .filter!(x => x > 4) .foo(); ``` ```d auto bar = iota(1, 100) .map!(x => x + 1) .filter!(x => x > 4) .foo(); ``` Code like this is going to be written and I didnt saw discussions about it or any other potential reduction in scanability of a code as a result of the proposed changes. Before starting to write in this thread I looked at how setters shorter syntax. 3 out of 3 videos did not feature this shorter syntax for one line functions. Any guesses as to why?
Jun 30
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 7/1/22 02:06, welkam wrote:
 On Tuesday, 28 June 2022 at 16:32:46 UTC, Timon Gehr wrote:
 Go language is the way it is for valid reasons. Don't dismiss them 
 easily.
Why not? I dislike Go for valid reasons.
I dont like Go as a language as well but I can still recognize that simplicity and uniformity is a valuable thing.
Go is neither simple nor uniform. The DIP is making D a bit simpler and more uniform.
 Now its crystal clear 
 that I was unable to effectively communicate what I was thinking. The 
 problem is that I dont know how else should I did it.
 
 Google has a problem that they constantly are hiring new programmers and 
 those programmers write code in their own way. Code bases written this 
 way are not optimal. Go being the way it is makes its so that it easier 
 to teach the language and its easier to onboard new programmer onto the 
 project.
I don't buy it, and neither should you or anyone else. https://programming.guide/go/go-gotcha.html https://fasterthanli.me/articles/lies-we-tell-ourselves-to-keep-using-golang
 I'm not going to list the negative trade offs of Go`s design 
 decisions as I believe its obvious for people in this forum. On the 
 other hand the benefits of Go or C designs seem to be valued at 0.
 
 Discussions here revolved around question "do you want these benefits or 
 not?" while it should have been "do you think the benefits are worth the 
 tradeoffs?". Instead of talking about the best case scenario of one line 
 functions in classes more time should have given to other possible uses 
 and its effects on readability.
 
 ```d
 auto bar() => iota(1, 100)
                      .map!(x => x + 1)
                      .filter!(x => x > 4)
                      .foo();
 ```
 
 ```d
 auto bar = iota(1, 100)
                  .map!(x => x + 1)
                  .filter!(x => x > 4)
                  .foo();
 ```
 Code like this is going to be written and I didnt saw discussions about 
 it or any other potential reduction in scanability of a code as a result 
 of the proposed changes.
 ...
I guess that's mostly because everyone else who has been inclined to join the discussion understands that this is very readable code. Also, I don't think you even understand what this DIP is proposing. The second snippet is already valid D code with or without this DIP.
 Before starting to write in this thread I looked at how setters and 

 syntax. 3 out of 3 videos did not feature this shorter syntax for one 
 line functions. Any guesses as to why?
They did not bother to update the videos. The shorthand syntax is a bit less general, and chances are people will just pick it up from encountering it in the wild. It's very obvious what it means. There is just not much to see here. There's much more productive things to argue about.
Jun 30
parent reply welkam <wwwelkam gmail.com> writes:
On Friday, 1 July 2022 at 01:10:28 UTC, Timon Gehr wrote:
 Go is neither simple nor uniform. The DIP is making D a bit 
 simpler and more uniform.
I guess we are still talking past each other. When I was talking about uniformity I was not talking about language rules. I was talking about code that is in the wild and how it looks. When you look at Go code thats in the wild it all look sameish. Thats the uniformity I talk about and I say it has value. Simplicity also has value. Sharing links that criticize Go`s foreign function interface does nothing to refute my statements especially when the blog you linked even support my statements.
After all, Go is an easy language to pick up
The code snippets I provided were intended to show visual similarities between function declaration and variable declaration with assignment. Currently lambdas appear in one context and function declarations in another. With this DIP function declarations with lambda pattern will start to appear in places where you can declare functions. In D`s case its practically everywhere. That means function declarations and variable declarations will be intermixed. Now look at this beautiful class. https://github.com/dlang/dmd/blob/4513d32447ddb1221581dd555b04851db6ec8afd/src/dmd/dmodule.d#L320 Imagine you need to work on it at Friday. Afternoon. While having poor sleep the night before. And the coffee run out. Try to count how many properties that class has. While counting in your mind try to insert function declarations in all possible places. See how things change. were just lazy to upate. Me personally I dont need things that make easy thing easier. I need things that make difficult things easier.
Jul 01
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 7/1/22 17:43, welkam wrote:
 On Friday, 1 July 2022 at 01:10:28 UTC, Timon Gehr wrote:
 Go is neither simple nor uniform. The DIP is making D a bit simpler 
 and more uniform.
I guess we are still talking past each other.
My understanding is that you said burn the DIP with fire (a rather drastic measure) and you are failing to back that up in a coherent way.
 When I was talking about 
 uniformity I was not talking about language rules. I was talking about 
 code that is in the wild and how it looks. When you look at Go code 
 thats in the wild it all look sameish.
There's always more than one way to do things. I lack the patience to go and seek out Go code to point out non-uniformities to you, so I won't try to refute this point, but it's a rather superficial one in any case.
 Thats the uniformity I talk about and I say it has value.
I understand your point, I just think it's very weak and fails to consider the whole picture.
 Simplicity also has value. Sharing links that 
 criticize Go`s foreign function interface does nothing to refute my 
 statements
Well, anyone who actually reads the article (and the previous one that is linked at the start) will easily see how it is in stark contrast to your statements while also criticizing Go's foreign function interface for a while, which in fact does actually relate to the overall point.
 especially when the blog you linked even support my statements.
 After all, Go is an easy language to pick up
...
It's sarcasm. Maybe read the article (or don't, this was mostly meant for readers that are actually interested). It's insightful. A bit more context to that quote:
 We've reached the fifth stage of grief: acceptance.
 Fine. It may well be that Go is not adequate for production services 
unless your shop is literally made up of Go experts (Tailscale) or you have infinite money to spend on engineering costs (Google).
 But surely there's still a place for it.
 After all, Go is an easy language to pick up (because it's so small, 
right?), and a lot of folks have learned it by now, so it's easy to recruit Go developers, so we can get lots of them on the cheap and just uhhh prototype a few systems?
 And then later when things get hard (as they always do at scale) 
we'll either rewrite it to something else, or we'll bring in experts, we'll figure something out.
 Except there is no such thing as throwaway code.
It's quoting those things (like you are) because they are the Go marketing gospel, but (in contrast to you) it's very critical of them.
 The code snippets I provided were intended to show visual similarities 
 between function declaration and variable declaration with assignment. 
Well, it's rather visually distinct to me. Anyway, I was under the impression that you like code that looks uniform to you.
 Currently lambdas appear in one context and function declarations in 
 another. With this DIP function declarations with lambda pattern will 
 start to appear in places where you can declare functions. In D`s case 
 its practically everywhere. That means function declarations and 
 variable declarations will be intermixed.
I am fine with that.
 Now look at this beautiful class.
 
 https://github.com/dlang/dmd/blob/4513d32447ddb1221581dd555b04851db6ec8afd/sr
/dmd/dmodule.d#L320 
You can't really use the DMD code base to make points about idiomatic D code. It's rather old, and does not use many of D's features as it's basically directly translated from the original C++ implementation.
 
 Imagine you need to work on it at Friday. Afternoon. While having poor 
 sleep the night before. And the coffee run out.
Can't relate. I never drink coffee and I avoid working while too tired, because that leads to better overall productivity.
 Try to count how many properties that class has. While counting in your 
 mind try to insert function declarations in all possible places. See how 
 things change.
 
 

 lazy to upate.
 ...
That's fine, neither do I. (And if you read my post you will notice I gave a more nuanced explanation for why it might be the case, though it's also pretty easy to stumble upon tutorials that do include it. Another point: Shorter videos tend to get more watchtime.)
 Me personally I dont need things that make easy thing easier. I need 
 things that make difficult things easier.
Reading code is often quite difficult and the DIP will often make it slightly easier, at almost zero implementation cost. It's a good trade-off. Many things that make difficult things easier are quite a bit more costly.
Jul 01
prev sibling next sibling parent reply WebFreak001 <d.forum webfreak.org> writes:
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

 [...]
I am a strong supporter of this change, I think this will help adoption a lot with several language and library constructs, especially with things like pattern matching with `std.sumtype`. I have already used the preview a bit in some of my code and I think it's a very good addition to do things like ```d int width() => shape.match!( (Box b) => b.width, (Circle c) => c.radius * 2 ); string name() => shape.match!(s => s.name); double calculateArea() => shape.match!(s => s.calculateArea); ``` rather than ```d int width() { return shape.match!( (Box b) => b.width, (Circle c) => c.radius * 2 ); } string name() { return shape.match!(s => s.name); } double calculateArea() { return shape.match!(s => s.calculateArea); } ``` I think the readability (understanding) is just as good as with the extended code, but it's much cleaner to look at, especially when there are many of these methods in sequence. I think this DIP would also increase property usage through methods. For tooling I don't see any problem, it's already implemented in libdparse and D-Scanner makes use of it already too. The syntax is consistent with lambdas and actually feels like it could have been in there since the start.
Jun 28
parent reply welkam <wwwelkam gmail.com> writes:
On Tuesday, 28 June 2022 at 11:25:53 UTC, WebFreak001 wrote:
 ```d
 int width() => shape.match!(
     (Box b) => b.width,
     (Circle c) => c.radius * 2
 );
 ```
Thank you for providing excellent example for an argument against this DIP. To a person who haven't coded in D for a while it was hard to understand what that code did. Also this is prime example to all people who talked about one line functions in classes that intentions != results. After looking at it for longer I think I can make this example a little more confusing. ```d int width() => shape.match!( (Box b) => b.width, (Circle c) => c.radius * 2 ); ```
Jun 28
next sibling parent rikki cattermole <rikki cattermole.co.nz> writes:
On 29/06/2022 1:38 AM, welkam wrote:
 Thank you for providing excellent example for an argument against this DIP.
The code that you are quoting is already valid D. ```d string name() => "abc"; double calculateArea() => 5.3f; ``` This is not and will be with this DIP. It is extending existing syntax to a place where it should have been supported all along.
Jun 28
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 28.06.22 15:38, welkam wrote:
 On Tuesday, 28 June 2022 at 11:25:53 UTC, WebFreak001 wrote:
 ```d
 int width() => shape.match!(
     (Box b) => b.width,
     (Circle c) => c.radius * 2
 );
 ```
Thank you for providing excellent example for an argument against this DIP. To a person who haven't coded in D for a while it was hard to understand what that code did.
Matching a couple of parentheses is not particularly D-specific.
Jun 28
prev sibling next sibling parent reply zjh <fqbqrr 163.com> writes:
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":
Have to establish this `concept`: `=>` is a `'one sentence function'`!
Jun 28
parent zjh <fqbqrr 163.com> writes:
On Tuesday, 28 June 2022 at 11:31:39 UTC, zjh wrote:

 Have to establish this `concept`: `=>` is a `'one sentence 
 function'`!
`Vim9` has come out, even `'VIM'` has `=>`!
Jun 28
prev sibling next sibling parent forkit <forkit gmail.com> writes:
On Wednesday, 15 June 2022 at 09:21:12 UTC, Mike Parker wrote:

I'd much rather be throwing my support behind a DIP that would 
give me the option for better encapsulating my class, than 
throwing my support behind something that is 'purely stylistic'.

But my gripes aside, yes, I do support this DIP.

As mentioned in the DIP, its is stylistically consistent with the 
use of lambda expressions in the composition of ranges, which I 
use alot.

Although it's not something I need, and not something I would 
find myself asking for, I recognise the benefits that others see 
in having it. And given it is stylistically consistent with 
features already in the language, I think it should be approved.
Jun 28
prev sibling parent Dukc <ajieskola gmail.com> writes:
On Wednesday, 15 June 2022 at 09:21:12 UTC, Mike Parker wrote:
 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.
I left specific feedback at the feedback thread, but I want to mention here that I still support this DIP. It's nothing groundbreaking, but small and simple improvements like this are just as important as grand schemes.
Jun 28