• Mike Parker (12/18) Sep 21 2022 DIP 1043, "Shortened Method Syntax", has been accepted.
• Mike Parker (3/4) Sep 21 2022 https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1043.md
• Meta (3/8) Sep 21 2022 That's awesome! Congrats to Max.
• Mike Parker (3/12) Sep 21 2022 And to Adam. I believe it's his implementation behind the preview
• Timon Gehr (3/29) Sep 21 2022 🎉
• Markus (4/11) Sep 21 2022 I kind of agree with Max's contention, but nonetheless, I quite
• ag0aep6g (7/11) Sep 21 2022 The benevolent way to read that is that Atila liked that he could easily...
• Doigt (6/18) Sep 21 2022 It's one of those things that aren't necessary, but bring some
• ryuukk_ (15/34) Sep 25 2022 It actually makes code very hard to read
• Dukc (12/27) Sep 24 2022 Excellent!
• Nick Treleaven (9/20) Sep 24 2022 Not just already implemented, but reviewed and merged by existing
• Guillaume Piolat (2/3) Sep 25 2022 Thanks Max for the DIP!

Mike Parker <aldacron gmail.com> writes:

DIP 1043, "Shortened Method Syntax", has been accepted.

The fact that the feature was already implemented behind a 
preview switch carried weight with Atila. He noted that, if not 
for that, he wasn't sure where he would stand on adding the 
feature, but he could see no reason to reject it now.

Walter accepted with a suggested (not a required) enhancement:

 It could be even shorter. For functions with no arguments, the 
 () could be

omitted, because the => token will still make it unambiguous.
For example:

     T front() => from;

becomes:

     T front => from;

As DIP author, Max decided against this. He said it's not a bad 
idea, but it's then "inconsistent with other the other syntaxes". 
If there is a demand for this, it would be easy to add later, but 
he felt it's better to keep things simple for now by going with 
the current implementation as is.

Mike Parker <aldacron gmail.com> writes:

On Wednesday, 21 September 2022 at 10:39:27 UTC, Mike Parker 
wrote:
 DIP 1043, "Shortened Method Syntax", has been accepted.

https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1043.md

Meta <jared771 gmail.com> writes:

On Wednesday, 21 September 2022 at 10:40:42 UTC, Mike Parker 
wrote:
 On Wednesday, 21 September 2022 at 10:39:27 UTC, Mike Parker 
 wrote:
 DIP 1043, "Shortened Method Syntax", has been accepted.

 https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1043.md

That's awesome! Congrats to Max.

Mike Parker <aldacron gmail.com> writes:

On Wednesday, 21 September 2022 at 13:56:35 UTC, Meta wrote:
 On Wednesday, 21 September 2022 at 10:40:42 UTC, Mike Parker 
 wrote:
 On Wednesday, 21 September 2022 at 10:39:27 UTC, Mike Parker 
 wrote:
 DIP 1043, "Shortened Method Syntax", has been accepted.

 https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1043.md

 That's awesome! Congrats to Max.

And to Adam. I believe it's his implementation behind the preview 
switch.

Timon Gehr <timon.gehr gmx.ch> writes:

On 21.09.22 12:39, Mike Parker wrote:
 DIP 1043, "Shortened Method Syntax", has been accepted.
 
 The fact that the feature was already implemented behind a preview 
 switch carried weight with Atila. He noted that, if not for that, he 
 wasn't sure where he would stand on adding the feature, but he could see 
 no reason to reject it now.
 
 Walter accepted with a suggested (not a required) enhancement:
 
 It could be even shorter. For functions with no arguments, the () 
 could be

 omitted, because the => token will still make it unambiguous.
 For example:

     T front() => from;

 becomes:

     T front => from;

 
 As DIP author, Max decided against this. He said it's not a bad idea, 
 but it's then "inconsistent with other the other syntaxes". If there is 
 a demand for this, it would be easy to add later, but he felt it's 
 better to keep things simple for now by going with the current 
 implementation as is.

🎉

Great news! :)

Markus <m ark.us.tld> writes:

On Wednesday, 21 September 2022 at 10:39:27 UTC, Mike Parker 
wrote:
For example:

     T front() => from;

becomes:

     T front => from;


I kind of agree with Max's contention, but nonetheless, I quite 
like it.

ag0aep6g <anonymous example.com> writes:

On 21.09.22 12:39, Mike Parker wrote:
 The fact that the feature was already implemented behind a preview 
 switch carried weight with Atila. He noted that, if not for that, he 
 wasn't sure where he would stand on adding the feature, but he could see 
 no reason to reject it now.

The benevolent way to read that is that Atila liked that he could easily 
try out the new feature and judge it more fairly because of that.

The mean way to read it is that Atila employs some circular reasoning: 
Accept the preview implementation, deferring to the DIP process to catch 
a bad proposal. Accept the DIP, referring to the preview implementation 
as justification.

Doigt <labog outlook.com> writes:

On Wednesday, 21 September 2022 at 10:39:27 UTC, Mike Parker 
wrote:
For example:

     T front() => from;

becomes:

     T front => from;

 As DIP author, Max decided against this. He said it's not a bad 
 idea, but it's then "inconsistent with other the other 
 syntaxes". If there is a demand for this, it would be easy to 
 add later, but he felt it's better to keep things simple for 
 now by going with the current implementation as is.

It's one of those things that aren't necessary, but bring some 
small "quality of life" kind of change to the code we write. At 
least in my opinion, I quite like it, the same way I like how I 
can call a parameter-less function without parentheses.

ryuukk_ <ryuukk.dev gmail.com> writes:

On Thursday, 22 September 2022 at 01:28:11 UTC, Doigt wrote:
 On Wednesday, 21 September 2022 at 10:39:27 UTC, Mike Parker 
 wrote:
For example:

     T front() => from;

becomes:

     T front => from;

 As DIP author, Max decided against this. He said it's not a 
 bad idea, but it's then "inconsistent with other the other 
 syntaxes". If there is a demand for this, it would be easy to 
 add later, but he felt it's better to keep things simple for 
 now by going with the current implementation as is.

 It's one of those things that aren't necessary, but bring some 
 small "quality of life" kind of change to the code we write. At 
 least in my opinion, I quite like it, the same way I like how I 
 can call a parameter-less function without parentheses.

It actually makes code very hard to read

Is it a field? is it a function, does it have arguments, or maybe 
it is just a static function, maybe it is a property, oh shoot i 
have to waste time trying to figure out what it is

It is same story with imprts, so now i exclusivly use named 
import ``import xxx = my.package.here`` 
``xx.my_global_function();``

This way when i read code, i know exactly what is doing what and 
from what module

This shortened method syntax is the same, it is a method, not a 
field, therefore it should require ``()``, i personally never 
omit it from the way i write function in my code, calling a 
function this way: ``this_is_a_function`` is imo very dangerous, 
i wish it was gone from the language

Dukc <ajieskola gmail.com> writes:

On Wednesday, 21 September 2022 at 10:39:27 UTC, Mike Parker 
wrote:
 DIP 1043, "Shortened Method Syntax", has been accepted.

Excellent!

 The fact that the feature was already implemented behind a 
 preview switch carried weight with Atila. He noted that, if not 
 for that, he wasn't sure where he would stand on adding the 
 feature, but he could see no reason to reject it now.

If there is no reason to reject an already-implemented feature, 
there's no reason to to reject it as non-implemented either.

If it feels like it's too much work to implement an otherwise 
good DIP, it should be accepted on the condition that someone 
does it, not rejected IMO.

Even if the maintainers don't have time to implement something 
themselves, it still lowers the bar a lot for someone else to do 
it when there is a promise to accept any sound implementation.

 Walter accepted with a suggested (not a required) enhancement:

 It could be even shorter. For functions with no arguments, the 
 () could be

 omitted, because the => token will still make it unambiguous.

 As DIP author, Max decided against this. He said it's not a bad 
 idea, but it's then "inconsistent with other the other 
 syntaxes". If there is a demand for this, it would be easy to 
 add later, but he felt it's better to keep things simple for 
 now by going with the current implementation as is.

Good reasoning from Max.

Nick Treleaven <nick geany.org> writes:

On Saturday, 24 September 2022 at 08:45:33 UTC, Dukc wrote:
 On Wednesday, 21 September 2022 at 10:39:27 UTC, Mike Parker 
 wrote:
 The fact that the feature was already implemented behind a 
 preview switch carried weight with Atila. He noted that, if 
 not for that, he wasn't sure where he would stand on adding 
 the feature, but he could see no reason to reject it now.

 If there is no reason to reject an already-implemented feature, 
 there's no reason to to reject it as non-implemented either.

Not just already implemented, but reviewed and merged by existing 
maintainers. It shows the feature was considered by trusted 
colleagues to be worth adding as a preview.

 If it feels like it's too much work to implement an otherwise 
 good DIP, it should be accepted on the condition that someone 
 does it, not rejected IMO.

DIPs for semantic features are much easier to review when there's 
an implementation so people can play with the feature and see how 
it interacts with the existing language. Basically the burden 
should be on the advocates to make their case, not on the 
maintainers to investigate an idea.

Guillaume Piolat <first.last spam.org> writes:

On Saturday, 24 September 2022 at 08:45:33 UTC, Dukc wrote:
 Good reasoning from Max.

Thanks Max for the DIP!