[Issue 7176] Lambda => syntax for function and methods too

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=7176

--- Comment #24 from Mathias LANG  ---
*** Issue 12288 has been marked as a duplicate of this issue. ***

--

[Issue 7176] Lambda => syntax for function and methods too

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=7176

Max Samukha  changed:

   What|Removed |Added

 CC||maxsamu...@gmail.com

--- Comment #23 from Max Samukha  ---
(In reply to Dlang Bot from comment #22)
> dlang/dmd pull request #11833 "Implement shortened methods with => syntax"
> was merged into master:
> 
> - e6850f8a241192e24869f9b7ad608b52706e1aa5 by Nicholas Lindsay Wilson:
> I am not convinced it is worth special-casing
>   the simple "=> y ALWAYS means "{ return y; }" rule for
>   this case and thus left it alone.
> 

C raises its ugly head again. With a proper unit type, "=> void.init;" would be
rewritten to "{ return void.init; }".

--

[Issue 7176] Lambda => syntax for function and methods too

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=7176

Dlang Bot  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #22 from Dlang Bot  ---
dlang/dmd pull request #11833 "Implement shortened methods with => syntax" was
merged into master:

- e6850f8a241192e24869f9b7ad608b52706e1aa5 by Nicholas Lindsay Wilson:
  Fix issue 7176: Implement shortened methods with => syntax

  For function literals, D offers a short syntax: `x => y`,
  which expands to `function (x) { return y; }`. However, for
  normal function definitions, there was no such shortening.
  For various applications, there can be more syntax than
  meaning, such as property accessors.

  This commit changes that by expanding the same `=>` syntax
  we already have to work in declarations as well. It expands
  to the same thing: `int foo() => x;` is simply
  `int foo() { return x; }`; this is just shortened syntax.
  Combined with existing rules like auto returns, a property
  getter can be be as simple as `@property x() => x_;` or a
  range-based pipeline may appear like
  `auto common_operation() => this[].sort.uniq;` giving D's
  existing functional strengths more syntax sugar.

  C# has demonstrated the utility of such shortened methods
  since its version 7. However, while C# allows it for
  constructors as well, this commit will parse it but fail
  in semantic because you cannot return a value from a
  constructor. I am not convinced it is worth special-casing
  the simple "=> y ALWAYS means "{ return y; }" rule for
  this case and thus left it alone.

https://github.com/dlang/dmd/pull/11833

--

[Issue 7176] Lambda => syntax for function and methods too

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=7176

Dlang Bot  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #21 from Dlang Bot  ---
@adamdruppe updated dlang/dmd pull request #11833 "Implement shortened methods
with => syntax" fixing this issue:

- Fix issue 7176: Implement shortened methods with => syntax

  For function literals, D offers a short syntax: `x => y`,
  which expands to `function (x) { return y; }`. However, for
  normal function definitions, there was no such shortening.
  For various applications, there can be more syntax than
  meaning, such as property accessors.

  This commit changes that by expanding the same `=>` syntax
  we already have to work in declarations as well. It expands
  to the same thing: `int foo() => x;` is simply
  `int foo() { return x; }`; this is just shortened syntax.
  Combined with existing rules like auto returns, a property
  getter can be be as simple as `@property x() => x_;` or a
  range-based pipeline may appear like
  `auto common_operation() => this[].sort.uniq;` giving D's
  existing functional strengths more syntax sugar.

  C# has demonstrated the utility of such shortened methods
  since its version 7. However, while C# allows it for
  constructors as well, this commit will parse it but fail
  in semantic because you cannot return a value from a
  constructor. I am not convinced it is worth special-casing
  the simple "=> y ALWAYS means "{ return y; }" rule for
  this case and thus left it alone.

https://github.com/dlang/dmd/pull/11833

--

[Issue 7176] Lambda => syntax for function and methods too

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=7176

--- Comment #20 from Nick Treleaven  ---
Just noticed C# 6.0 has this syntax, they call it "Expression Body
Definitions":
https://msdn.microsoft.com/en-us/library/ms173114.aspx#Anchor_6

C# also has the same (x, y) => x == y lambda syntax as D. C# having this
feature indicates the syntax may be worth adding.

Regarding function syntax consistency, we now allow lambdas to be used with
alias:

alias square = x => x ^ 2;
auto square(T)(T x) => x ^ 2; // proposed
auto square(T)(T x) {return x ^ 2;}

The proposed function definition syntax would be more consistent with the alias
(and more flexible than alias).

The main point of this request IMO is to reduce brace nesting, braces and
brackets are visually noisy and make the programmer have to mentally match them
up.

--

[Issue 7176] Lambda = syntax for function and methods too

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=7176

--- Comment #19 from Ketmar Dark ket...@ketmar.no-ip.org ---
Created attachment 1499
  -- https://issues.dlang.org/attachment.cgi?id=1499action=edit
working PoC with samples

--

[Issue 7176] Lambda = syntax for function and methods too

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=7176



--- Comment #15 from bearophile_h...@eml.cc 2013-03-20 06:13:22 PDT ---
After having used Scala a little, I now have changed my mind a little again.

In Scala you write:

def f3(x: Int, y: Int): Int = if (x == 0) x else x * y


This is current valid D code:

int f1(int x, int y) { return (x == 0) ? x : x ^^ 2; }

const f2 = (int x, int y) = (x == 0) ? x : x ^^ 2;



Allowing this in D is nice to reduce some syntax noise. So I now like this
idea:

int f4(int x, int y) = (x == 0) ? x : x ^^ 2;


In functional-style programming very short functions are common.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 7176] Lambda = syntax for function and methods too

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=7176


Nick Treleaven ntrel-pub...@yahoo.co.uk changed:

   What|Removed |Added

 CC||ntrel-pub...@yahoo.co.uk


--- Comment #16 from Nick Treleaven ntrel-pub...@yahoo.co.uk 2013-03-20 
07:15:30 PDT ---
(In reply to comment #7)
 I could really have a use for this. I have a lot of methods that just returns 
 a
 single expression.

I thought I'd add some hard data on this. There are quite a lot of these in
Phobos (edited results to only show larger count items):

$ git grep -Ec '\{\s*return\b' std/
std/algorithm.d:77
std/cpuid.d:27
std/format.d:35
std/functional.d:37
std/math.d:31
std/range.d:86
std/regex.d:44
std/traits.d:71
std/typecons.d:54
std/variant.d:23
std/xml.d:24

Admittedly, some of these may be false positives for e.g. lambdas, but a quick
scan through the results shows they are almost all one line function/method
definitions. I think this demonstrates a significant use case for the proposed
syntax.

 Another idea would be to allow optional braces for methods and functions, just
 as for if-statements.

That might not be ideal syntax with template constraints:
void foo(T)(T v) if (isFoo!T) writeln(v);
void foo(T)(T v) if (isFoo!T) = writeln(v);

The second syntax is clearer in distinguishing the constraint from if statement
syntax IMO.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 7176] Lambda = syntax for function and methods too

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=7176



--- Comment #17 from Kenji Hara k.hara...@gmail.com 2013-03-20 08:21:44 PDT 
---
I don't like this feature. Because:

1. it would reduce code readability.

   class LibClass {
 int foo() { return 1; }
 string bar() = hi;
   }

   Mixing lambda syntax and normal function syntax looks messy.

2. Just only reducing 7 character is too small benefit.

   auto foo()=expr;
   auto foo(){return expr;}

   With more complex function signature:

   ComplexReturnType!(..) foo(T, U, V)(T t, U u, V v) if (...)=expr;
   ComplexReturnType!(..) foo(T, U, V)(T t, U u, V v) if (...){return expr;}

   Ratio will fall further.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 7176] Lambda = syntax for function and methods too

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=7176



--- Comment #18 from timon.g...@gmx.ch 2013-03-20 13:33:49 PDT ---
(In reply to comment #17)
 I don't like this feature. Because:
 
 1. it would reduce code readability.
 

On the contrary! It also increases language consistency.

class LibClass {
  int foo() { return 1; }
  string bar() = hi;
}
 
Mixing lambda syntax and normal function syntax looks messy.
 

No. It is normal function syntax that looks messy in this case.

class LibClass {
auto foo() = 1;
auto bar() = hi;
}


 2. Just only reducing 7 character is too small benefit.
 

7*_N_ characters. Also, it can get rid of additional indentation.

auto foo()=expr;
auto foo(){return expr;}
 
With more complex function signature:
 
ComplexReturnType!(..) foo(T, U, V)(T t, U u, V v) if (...)=expr;
ComplexReturnType!(..) foo(T, U, V)(T t, U u, V v) if (...){return expr;}
 
Ratio will fall further.

This is not a valid argument in any case.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 7176] Lambda = syntax for function and methods too

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=7176


Artem Borisovskiy kolo...@bk.ru changed:

   What|Removed |Added

 CC||kolo...@bk.ru


--- Comment #10 from Artem Borisovskiy kolo...@bk.ru 2012-07-20 05:37:43 PDT 
---
 class Foo
 {
 @property int bar;
 }
 
 Is lowered to this:
 
 class Foo
 {
 private int bar_;
 
 @property int bar () { return bar_; }
 @property int bar (int value) { return bar_ = value; }
 }

Why not just make bar_ public? You do not add any code to the getter nor to the
setter anyway.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 7176] Lambda = syntax for function and methods too

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=7176



--- Comment #11 from Jacob Carlborg d...@me.com 2012-07-20 07:06:34 PDT ---
(In reply to comment #10)

 Why not just make bar_ public? You do not add any code to the getter nor to 
 the
 setter anyway.

Perhaps I want it to be virtual, to be able to override it in a subclass.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 7176] Lambda = syntax for function and methods too

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=7176



--- Comment #12 from David Piepgrass qwertie...@gmail.com 2012-07-20 08:59:15 
PDT ---
(In reply to comment #11)
 (In reply to comment #10)
  Why not just make bar_ public? You do not add any code to the getter nor to 
  the
  setter anyway.
 
 Perhaps I want it to be virtual, to be able to override it in a subclass.

Yes, or, quite often I want to write a trivial getter but a nontrivial setter.
So I'd like just the getter for free. Also, when the interface is going to be
exported, even a trivial property should often be a property instead of a
field, to avoid breaking binary compatibility if one changes one's mind and
wants to make it a property later (actually this even affects source
compatibility--a property can't be passed by reference).

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 7176] Lambda = syntax for function and methods too

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=7176



--- Comment #13 from Jonathan M Davis jmdavisp...@gmx.com 2012-07-20 10:06:53 
PDT ---
 Yes, or, quite often I want to write a trivial getter but a nontrivial setter.
 So I'd like just the getter for free. Also, when the interface is going to be
 exported, even a trivial property should often be a property instead of a
 field, to avoid breaking binary compatibility if one changes one's mind and
 wants to make it a property later (actually this even affects source
 compatibility--a property can't be passed by reference).

That's why I've been tempted to suggest that @property on a variable made it so
that only operations which would still be legal if it were switched to being a
property function were allowed. I can't remember whether I ever actually opened
an enhancement request on that though. I'd have to go digging to find out.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 7176] Lambda = syntax for function and methods too

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=7176



--- Comment #14 from Jacob Carlborg d...@me.com 2012-07-20 10:22:44 PDT ---
(In reply to comment #12)

 Yes, or, quite often I want to write a trivial getter but a nontrivial setter.
 So I'd like just the getter for free. Also, when the interface is going to be
 exported, even a trivial property should often be a property instead of a
 field, to avoid breaking binary compatibility if one changes one's mind and
 wants to make it a property later (actually this even affects source
 compatibility--a property can't be passed by reference).

Other good points.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 7176] Lambda = syntax for function and methods too

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=7176



--- Comment #9 from Jacob Carlborg d...@me.com 2012-07-18 23:20:18 PDT ---
(In reply to comment #8)

 On the other hand, a lot of the small functions I write are boilerplate such 
 as
 property getters and forwarding functions in decorators, so maybe instead of a
 special lambda syntax, what I really want is a few metaprograms to write those
 functions for me.

I wouldn't mind some kind of property shortcut, like this:

class Foo
{
@property int bar;
}

Is lowered to this:

class Foo
{
private int bar_;

@property int bar () { return bar_; }
@property int bar (int value) { return bar_ = value; }
}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 7176] Lambda = syntax for function and methods too

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=7176


David Piepgrass qwertie...@gmail.com changed:

   What|Removed |Added

 CC||qwertie...@gmail.com


--- Comment #8 from David Piepgrass qwertie...@gmail.com 2012-07-18 17:45:27 
PDT ---
+1 from me. Limited C compatibility is one thing, but why should everything in
D look like C? Although I've written more code in C/C++ than any other
language, I haven't enjoyed it for many years now. I want a language that makes
me more productive, and I often use small functions (many of which return void
regardless of the expression type, btw, so that should be allowed.)

On the other hand, a lot of the small functions I write are boilerplate such as
property getters and forwarding functions in decorators, so maybe instead of a
special lambda syntax, what I really want is a few metaprograms to write those
functions for me.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 7176] Lambda = syntax for function and methods too

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=7176


Jacob Carlborg d...@me.com changed:

   What|Removed |Added

 CC||d...@me.com


--- Comment #7 from Jacob Carlborg d...@me.com 2012-01-03 23:30:48 PST ---
I could really have a use for this. I have a lot of methods that just returns a
single expression.

Another idea would be to allow optional braces for methods and functions, just
as for if-statements. This could be extended to all language features where
braces are used to make it more consistent.

In addition to the above we could make implicit returns possible to all
functions and methods.

I don't know which of these two ideas are farthest away from the normal C-based
syntax.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 7176] Lambda = syntax for function and methods too

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=7176



--- Comment #1 from bearophile_h...@eml.cc 2012-01-03 16:07:57 PST ---
There are 3 votes now. But this feature doesn't add a lot to D. This feature
looks nice, but I don't feel a need for it in my code.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 7176] Lambda = syntax for function and methods too

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=7176


Jonathan M Davis jmdavisp...@gmx.com changed:

   What|Removed |Added

 CC||jmdavisp...@gmx.com


--- Comment #2 from Jonathan M Davis jmdavisp...@gmx.com 2012-01-03 16:28:36 
PST ---
It would be too much of a departure from the normal syntax to enable the new
lambda syntax in general IMHO. It's useful for lambdas simply because without
it they risk being very verbose in what is already fairly dense code. Function
declarations don't really have that problem. Yes, the syntax is a bit verbose
if all you're doing is returning a value, but most functions do more than that,
and most functions are not declared in the midst of dense code like you
typically get with lambdas. This enhancement request is such a drastic
departure from the normal C-based syntax that I think that it would cause far
more harm than good.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 7176] Lambda = syntax for function and methods too

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=7176


timon.g...@gmx.ch changed:

   What|Removed |Added

 CC||timon.g...@gmx.ch


--- Comment #3 from timon.g...@gmx.ch 2012-01-03 16:40:47 PST ---
It is the same 'departure' as the one caused by the introduction of the new
lambda literals and therefore I cannot see how it can possibly cause any harm.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 7176] Lambda = syntax for function and methods too

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=7176



--- Comment #4 from Jonathan M Davis jmdavisp...@gmx.com 2012-01-03 16:48:12 
PST ---
It's very different IMHO to introduce it in lambdas which are already part of
an expression and where the number of characters definitely matters than it is
to introduce it in normal function declarations. With declarations, they're on
their own instead of part of a larger expression. They just don't present the
same kind of gain and therefore don't merit the cost of the large departure in
syntax IMHO.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 7176] Lambda = syntax for function and methods too

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=7176



--- Comment #5 from bearophile_h...@eml.cc 2012-01-03 16:54:10 PST ---
(In reply to comment #2)

Currently I am neutral toward this feature. I see it used in Scala and it looks
nice, but I don't think it will improve my D programs a lot.


 This enhancement request is such a drastic
 departure from the normal C-based syntax that I think that it would cause far
 more harm than good.

What kind of harm are you referring to?

I think it's not significantly bug-prone, and being already present in the
language (as lambda syntax) doesn't add a lot of complexity for the person that
has to learn D.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 7176] Lambda = syntax for function and methods too

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=7176



--- Comment #6 from Jonathan M Davis jmdavisp...@gmx.com 2012-01-03 19:10:35 
PST ---
 What kind of harm are you referring to?

It doesn't fit with the rest of the language. The syntax is very different from
other declarations. This reduces readability and increases how much the
programmer has to deal with.

The verboseness of lambda expressions is a definite problem for readability, so
the syntax is arguably worth it for lambda expressions. But to then also use it
in declarations which don't have the same readibility problem is incurring that
cost where it's not worth it IMHO.

Obviously, this is perfectly valid as an enhancement request, but I hope that
the request is denied. I think that the lambda syntax is too different from
typical C-based syntax to be reasonable in normal function declarations.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---