Re: DIP 1043---Shortened Method Syntax---Accepted

[Nick Treleaven via Digitalmars-d-announce]

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.

Re: Beerconf September 2022

[rikki cattermole via Digitalmars-d-announce]

Linkity link: https://meet.jit.si/Dlang2022SeptemberBeerConf

Re: DIP 1043---Shortened Method Syntax---Accepted

[Dukc via Digitalmars-d-announce]

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.