Menu
Search

Forums

Forum Index

February 05, 2022
Gravatar of Paul BackusPosted by Paul Backus
in reply to forkit		Reply
Paul Backus
Gravatar of Paul Backus
Posted in reply to forkit


Reply
On Saturday, 5 February 2022 at 08:12:32 UTC, forkit wrote:
> It is clear that the D programming language is really more 'a collection of dialects', including those whose only real value, is that they save you a few keystrokes.
>
> That's the upside of the proposal I assume?
>
> The downside, is the additional cognitive load.

D already supports this shortened syntax for anonymous functions:

    (int x) { return x + 1; }
    (int x) => x + 1

So, allowing it for named functions too is a logical extension of a language feature that already exists.
February 05, 2022
Gravatar of DoigtPosted by Doigt
in reply to bauss		Reply
Doigt
Gravatar of Doigt
Posted in reply to bauss


Reply

On Saturday, 5 February 2022 at 00:17:23 UTC, bauss wrote:

>

On Friday, 4 February 2022 at 10:53:45 UTC, Mike Parker wrote:

>

Discussion Thread

This is the discussion thread for the first round of Community
Review of DIP 1043, "Shortened Method Syntax":

https://github.com/dlang/DIPs/blob/5a3b437f2b6be8fb23e855fc0da20f19f68edac8/DIPs/DIP1043.md

The review period will end at 11:59 PM ET on February 18, 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 that I
will 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.

From the DIP itself it wasn't clear to me whether it would only support expressions that returns a value or not, because to me it should also support expressions that don't necessarily yield a value.

So both these would be valid:

void foo() { ... }
void bar() => foo(); // This

private int _value;
void baz(int value) => _value = value; // And this
int baz() => _value;

If it's supported then I'm all for this, but if not then I think it's only a half-baked implementation.

I completely agree. Coming from C# where lambda notation on void is allowed, it seems weird to me that it doesn't always work no matter what kind of method you're using it on. If anything it introduces an inconsistency in the syntax and makes it very inconvenient because it also introduces style inconsistency where if your code uses single line functions side by side and some use the arrow notation and others don't because it's not possible by an arbitrary opinion that it shouldn't be possible. To me such thinking seems rooted in the past.

February 06, 2022
Gravatar of rikki cattermolePosted by rikki cattermole
in reply to Paul Backus		Reply
rikki cattermole
Gravatar of rikki cattermole
Posted in reply to Paul Backus


Reply
On 06/02/2022 3:10 AM, Paul Backus wrote:
> So, allowing it for named functions too is a logical extension of a language feature that already exists.

Yes.

A lot of the point of this DIP is to make D more consistent.

For stuff like this you should be able to guess that a feature exists and the language is like yup! It totally does the thing you think it does.

In a lot of ways this simplifies D, as it no longer has a special case where this is syntax is possible.
February 05, 2022
Gravatar of Paul BackusPosted by Paul Backus
in reply to Doigt		Reply
Paul Backus
Gravatar of Paul Backus
Posted in reply to Doigt


Reply

On Saturday, 5 February 2022 at 14:13:50 UTC, Doigt wrote:

>

On Saturday, 5 February 2022 at 00:17:23 UTC, bauss wrote:

> 
void foo() { ... }
void bar() => foo(); // This

private int _value;
void baz(int value) => _value = value; // And this
int baz() => _value;

If it's supported then I'm all for this, but if not then I think it's only a half-baked implementation.

I completely agree. Coming from C# where lambda notation on void is allowed, it seems weird to me that it doesn't always work no matter what kind of method you're using it on. If anything it introduces an inconsistency in the syntax and makes it very inconvenient because it also introduces style inconsistency where if your code uses single line functions side by side and some use the arrow notation and others don't because it's not possible by an arbitrary opinion that it shouldn't be possible. To me such thinking seems rooted in the past.

=> expression is shorthand for { return expression; }, and the type of the expression _value = value is int, not void, so you get a type mismatch. Seems pretty straightforward to me. If anything, adding a special case for void functions would make it less consistent and more arbitrary.

Maybe there's an argument to be made that the compiler should allow this kind of return statement in void functions in general, regardless of whether you use the short or long syntax. But that's a totally separate issue from this DIP's proposal.

February 05, 2022
Gravatar of DoigtPosted by Doigt
in reply to Paul Backus		Reply
Doigt
Gravatar of Doigt
Posted in reply to Paul Backus


Reply

On Saturday, 5 February 2022 at 14:22:07 UTC, Paul Backus wrote:

>

On Saturday, 5 February 2022 at 14:13:50 UTC, Doigt wrote:

>

On Saturday, 5 February 2022 at 00:17:23 UTC, bauss wrote:

> 
void foo() { ... }
void bar() => foo(); // This

private int _value;
void baz(int value) => _value = value; // And this
int baz() => _value;

If it's supported then I'm all for this, but if not then I think it's only a half-baked implementation.

I completely agree. Coming from C# where lambda notation on void is allowed, it seems weird to me that it doesn't always work no matter what kind of method you're using it on. If anything it introduces an inconsistency in the syntax and makes it very inconvenient because it also introduces style inconsistency where if your code uses single line functions side by side and some use the arrow notation and others don't because it's not possible by an arbitrary opinion that it shouldn't be possible. To me such thinking seems rooted in the past.

=> expression is shorthand for { return expression; }, and the type of the expression _value = value is int, not void, so you get a type mismatch. Seems pretty straightforward to me. If anything, adding a special case for void functions would make it less consistent and more arbitrary.

Maybe there's an argument to be made that the compiler should allow this kind of return statement in void functions in general, regardless of whether you use the short or long syntax. But that's a totally separate issue from this DIP's proposal.

Except commonly, and to take two popular examples: JavaScript and C#, the arrow notation is not understood to be a shorthand for a return expression but just an expression. I don't think I'll use this new feature if I can't make my code base consistent in style. It makes no sense to me to have things like
int myFunc (int a) => something;
void myProc (int a) { something; }
it looks bad and it makes it seems like void is a special case that is not immediately obvious why the arrow notation is not used.

February 05, 2022
Gravatar of Ola Fosheim GrøstadPosted by Ola Fosheim Grøstad
in reply to Paul Backus		Reply
Ola Fosheim Grøstad
Gravatar of Ola Fosheim Grøstad
Posted in reply to Paul Backus


Reply

On Saturday, 5 February 2022 at 14:10:51 UTC, Paul Backus wrote:

>

D already supports this shortened syntax for anonymous functions:

(int x) { return x + 1; }
(int x) => x + 1

So, allowing it for named functions too is a logical extension of a language feature that already exists.

Hardly, I would read arrow as a math-like lambda by convention.

February 05, 2022
Gravatar of forkitPosted by forkit
in reply to Ola Fosheim Grøstad		Reply
forkit
Gravatar of forkit
Posted in reply to Ola Fosheim Grøstad


Reply
On Saturday, 5 February 2022 at 20:15:33 UTC, Ola Fosheim Grøstad wrote:
> On Saturday, 5 February 2022 at 14:10:51 UTC, Paul Backus wrote:
>> D already supports this shortened syntax for anonymous functions:
>>
>>     (int x) { return x + 1; }
>>     (int x) => x + 1
>>
>> So, allowing it for named functions too is a logical extension of a language feature that already exists.
>
> Hardly, I would read arrow as a math-like lambda by convention.

The proposal seems straight forward to me:

auto multiplyBy10 = (int a) => a * 10; // already exists.
auto multiplyBy10(int x) => x * 10; // proposed: Shortened Method Syntax

Nothing to see here.

Just do it.
February 05, 2022
Gravatar of Ola Fosheim GrøstadPosted by Ola Fosheim Grøstad
in reply to forkit		Reply
Ola Fosheim Grøstad
Gravatar of Ola Fosheim Grøstad
Posted in reply to forkit


Reply

On Saturday, 5 February 2022 at 20:47:02 UTC, forkit wrote:

>

auto multiplyBy10 = (int a) => a * 10; // already exists.
auto multiplyBy10(int x) => x * 10; // proposed: Shortened Method Syntax

I don't really care either way. It is in general a bad idea to have to syntaxes for the same thing.

It is certainly not logical though.

Lambdas conceptualize mathematical expressions.
Methods conceptualize messages.

Two different modelling ideas.

February 05, 2022
Gravatar of Guillaume PiolatPosted by Guillaume Piolat
in reply to Ola Fosheim Grøstad		Reply
Guillaume Piolat
Gravatar of Guillaume Piolat
Posted in reply to Ola Fosheim Grøstad


Reply

On Saturday, 5 February 2022 at 21:17:23 UTC, Ola Fosheim Grøstad wrote:

>

I don't really care either way.

Same.

February 05, 2022
Gravatar of forkitPosted by forkit
in reply to Ola Fosheim Grøstad		Reply
forkit
Gravatar of forkit
Posted in reply to Ola Fosheim Grøstad


Reply
On Saturday, 5 February 2022 at 21:17:23 UTC, Ola Fosheim Grøstad wrote:
> On Saturday, 5 February 2022 at 20:47:02 UTC, forkit wrote:
>> auto multiplyBy10 = (int a) => a * 10; // already exists.
>> auto multiplyBy10(int x) => x * 10; // proposed: Shortened Method Syntax
>
> I don't really care either way. It is in general a bad idea to have to syntaxes for the same thing.
>
> It is certainly not logical though.
>
> Lambdas conceptualize mathematical expressions.
> Methods conceptualize messages.
>
> Two different modelling ideas.

I agree.

The real issue, is how developers decide the case for when to use, and when not to use one style of the other. Irregular mixing of the two dialects would not constitute good coding style in my opinion.

My primary concern about integrating mathmatical expressions like these into a programming language, has always been the extent to which one can understand them without training.

This continual evolution towards making programming languages appear more like Frisian, is in nobodys interest.. unless you already speak Frisian.
« First   ‹ Prev
1 2 3 4 5 6
Next ›   Last »