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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022



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 2022