digitalmars.D.bugs - [Issue 7176] New: Lambda => syntax for function and methods too
- d-bugmail puremagic.com (31/32) Dec 28 2011 http://d.puremagic.com/issues/show_bug.cgi?id=7176
- d-bugmail puremagic.com (7/7) Jan 03 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7176
- d-bugmail puremagic.com (18/18) Jan 03 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7176
- d-bugmail puremagic.com (11/11) Jan 03 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7176
- d-bugmail puremagic.com (11/11) Jan 03 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7176
- d-bugmail puremagic.com (12/15) Jan 03 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7176
- d-bugmail puremagic.com (15/16) Jan 03 2012 It doesn't fit with the rest of the language. The syntax is very differe...
- d-bugmail puremagic.com (18/18) Jan 03 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7176
- d-bugmail puremagic.com (18/18) Jul 18 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7176
- d-bugmail puremagic.com (18/22) Jul 18 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7176
- d-bugmail puremagic.com (11/25) Jul 20 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7176
- d-bugmail puremagic.com (7/9) Jul 20 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7176
- d-bugmail puremagic.com (12/17) Jul 20 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7176
- d-bugmail puremagic.com (9/15) Jul 20 2012 That's why I've been tempted to suggest that @property on a variable mad...
- d-bugmail puremagic.com (7/13) Jul 20 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7176
- d-bugmail puremagic.com (15/15) Mar 20 2013 http://d.puremagic.com/issues/show_bug.cgi?id=7176
- d-bugmail puremagic.com (33/37) Mar 20 2013 http://d.puremagic.com/issues/show_bug.cgi?id=7176
- d-bugmail puremagic.com (19/19) Mar 20 2013 http://d.puremagic.com/issues/show_bug.cgi?id=7176
- d-bugmail puremagic.com (14/36) Mar 20 2013 http://d.puremagic.com/issues/show_bug.cgi?id=7176
http://d.puremagic.com/issues/show_bug.cgi?id=7176 Summary: Lambda => syntax for function and methods too Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: DMD AssignedTo: nobody puremagic.com ReportedBy: bearophile_hugs eml.cc (From an idea of Timon Gehr) I think extending the applicability of the new lambda syntax to free functions/methods is a nice idea, to shorten tiny functions/methods, that are common enough: struct C { int x; int getX() => x; int sqrX() => x ^^ 2; } Some examples from other languages: A function to compute the arithmetic mean in Scala 2.7: def mean(s: Seq[Int]) = s.foldLeft(0)(_+_) / s.size From the Ada 2012 changes: http://www.disca.upv.es/jorge/ae2010/slides/05-3_Language_Tech_Schonberg_Towards_Ada_2012.pdfTo simplify the writing of pre/postconditions and predicates, allow parametrized expressions (aka function bodies in package specs):function Cube (X : integer) is (X ** 3); -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Dec 28 2011
http://d.puremagic.com/issues/show_bug.cgi?id=7176 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: -------
Jan 03 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7176 Jonathan M Davis <jmdavisProg gmx.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jmdavisProg gmx.com 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: -------
Jan 03 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7176 timon.gehr gmx.ch changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |timon.gehr gmx.ch 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: -------
Jan 03 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7176 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: -------
Jan 03 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7176 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: -------
Jan 03 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7176 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: -------
Jan 03 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7176 Jacob Carlborg <doob me.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |doob me.com 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: -------
Jan 03 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7176 David Piepgrass <qwertie256 gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |qwertie256 gmail.com 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: -------
Jul 18 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7176On 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: -------
Jul 18 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7176 Artem Borisovskiy <kolos80 bk.ru> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kolos80 bk.ru ---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: -------
Jul 20 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7176Why 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: -------
Jul 20 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7176 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). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------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.
Jul 20 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7176 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: -------
Jul 20 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7176Yes, 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: -------
Jul 20 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7176 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: -------
Mar 20 2013
http://d.puremagic.com/issues/show_bug.cgi?id=7176 Nick Treleaven <ntrel-public yahoo.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ntrel-public yahoo.co.uk 07:15:30 PDT ---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: -------
Mar 20 2013
http://d.puremagic.com/issues/show_bug.cgi?id=7176 --- 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: -------
Mar 20 2013
http://d.puremagic.com/issues/show_bug.cgi?id=7176I 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: -------
Mar 20 2013