Jump to page: 1 2
Thread overview
DIP 1043---Shortened Method Syntax---Accepted
Sep 21
Meta
Sep 21
Markus
Sep 22
ag0aep6g
Sep 22
Doigt
Sep 25
ryuukk_
Sep 24
Dukc
September 21

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.

September 21

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

September 21
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! :)
September 21

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.

September 21

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.

September 21

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.

September 22
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.
September 22

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.

September 24

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.

September 24

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.

« First   ‹ Prev
1 2