June 28, 2022

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.

June 28, 2022

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.

June 28, 2022

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

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

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.

June 28, 2022

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'!

June 28, 2022

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.

June 28, 2022

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.

June 28, 2022

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.

June 28, 2022
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.

June 28, 2022

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.

June 28, 2022

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.