www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - A nice way to step into 2012

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc

Andrei
Dec 26 2011
next sibling parent "Masahiro Nakagawa" <repeatedly gmail.com> writes:
On Tuesday, 27 December 2011 at 04:25:00 UTC, Andrei Alexandrescu 
wrote:

 https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc

 Andrei


This change is cooooool!


Masahiro
Dec 26 2011
prev sibling next sibling parent "Nick Sabalausky" <a a.a> writes:
"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:jdbhas$2ftb$1 digitalmars.com...

 https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc

 Andrei


Fanfuckingtastic!
Dec 26 2011
prev sibling next sibling parent reply Long Chang <changedalone gmail.com> writes:
Lambda very cooooool!

I hope we can add shared lib support for linux & freebsd in 2012.


On 27 December 2011 12:25, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:

 https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc

 Andrei
Dec 26 2011
parent reply Jacob Carlborg <doob me.com> writes:
On 2011-12-27 07:00, Long Chang wrote:

 Lambda very cooooool!

 I hope we can add shared lib support for linux&  freebsd in 2012.


 On 27 December 2011 12:25, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org>  wrote:

 https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc

 Andrei




And Mac OS X.

-- 
/Jacob Carlborg
Dec 27 2011
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/27/11 2:38 PM, Jacob Carlborg wrote:

 On 2011-12-27 07:00, Long Chang wrote:

 Lambda very cooooool!

 I hope we can add shared lib support for linux& freebsd in 2012.


 On 27 December 2011 12:25, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc


 Andrei




 And Mac OS X.


Win64 comes to mind.

Andrei
Dec 27 2011
prev sibling next sibling parent "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Tuesday, 27 December 2011 at 04:25:00 UTC, Andrei Alexandrescu 
wrote:

 https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc

 Andrei


Finally, it's here! I'll be able to use std.algorithm stuff 
without tons of named, nested functions now :)
Dec 27 2011
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:


 https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc


Since some time thanks to a post in this newsgroups I am able to compile DMD,
so I am able to test the changes early. It seems to work in various situations:


import std.stdio, std.range, std.algorithm;
int foo(alias callMe)(int a) {
    return callMe(a);
}
int bar(alias callMe)() {
    return callMe(1, 10, 100);
}
void main() {
    auto r = foo!((x) => x ^^ 2)(4);
    assert(r == 16);
    r = foo!((x,) => x ^^ 2)(5);
    assert(r == 25);
    // r = foo!((x,,) => x ^^ 2)(5); // error, good
    r = foo!(x=>x^^2)(6);
    assert(r == 36);
    r = bar!((x, y, z) => x + y + z)();
    assert(r == 111);
    double delegate(double)[] f;
    f ~= (double x) => x ^^ 2;
    assert(f[0](10) == 100);
    // Syntax variety, fit for everyone:
    auto pow4 = (int x) => x ^^ 4;
    writeln(map!(function int(in int x) pure nothrow { return x ^^ 4;
})(iota(10)));
    writeln(map!(function int(int x){ return x ^^ 4; })(iota(10)));
    writeln(map!(function(int x){ return x ^^ 4; })(iota(10)));
    writeln(map!((int x){ return x ^^ 4; })(iota(10)));
    writeln(map!((x){ return x ^^ 4; })(iota(10)));
    writeln(map!((int x) => x ^^ 4)(iota(10)));
    writeln(map!((x) => x ^^ 4)(iota(10)));
    writeln(map!(x => x ^^ 4)(iota(10)));
    writeln(map!q{ a ^^ 4 }(iota(10)));
    writeln(map!"a^^4"(iota(10)));
    writeln(map!pow4(iota(10)));
}

-----------------------

This program contains wrong syntax because x lacks a type:

void main() {
    double delegate(double) f;
    f = (x) => x + 1;
}


DMD gives the error messages:

test.d(3): Error: undefined identifier x, did you mean variable f?
test.d(3): Error: cannot implicitly convert expression (__dgliteral1) of type
_error_ delegate(_error_) to double delegate(double)

Is it wise to try to improve the second error message?

Bye,
bearophile
Dec 27 2011
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/27/11 3:35 AM, bearophile wrote:

 This program contains wrong syntax because x lacks a type:

 void main() {
      double delegate(double) f;
      f = (x) =>  x + 1;
 }


 DMD gives the error messages:

 test.d(3): Error: undefined identifier x, did you mean variable f?
 test.d(3): Error: cannot implicitly convert expression (__dgliteral1) of type
_error_ delegate(_error_) to double delegate(double)

 Is it wise to try to improve the second error message?


Actually that's an old bug in the compiler. Lambdas without parameter 
types are really templates, and a template should be assignable to a 
function or delegate if the parameter type binding works.


Andrei
Dec 27 2011
prev sibling next sibling parent reply deadalnix <deadalnix gmail.com> writes:
Le 27/12/2011 05:25, Andrei Alexandrescu a écrit :

 https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc


 Andrei


Maybe I'll seem bitter, but I do not think this changement was really 
that important. This is nice, ok, but we have some other really serious 
flaw, like shared not doing what it is supposed to do.
Dec 27 2011
next sibling parent reply Peter Alexander <peter.alexander.au gmail.com> writes:
On 27/12/11 10:51 AM, deadalnix wrote:

 Le 27/12/2011 05:25, Andrei Alexandrescu a écrit :

 https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc



 Andrei


 Maybe I'll seem bitter, but I do not think this changement was really
 that important. This is nice, ok, but we have some other really serious
 flaw, like shared not doing what it is supposed to do.


You seem bitter :-)

Seriously though, it's a fair point, but the syntax of lambdas is fairly 
important and this appears to be a simple change so the cost/benefit 
ratio is particularly high in this case.
Dec 27 2011
parent reply "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Tuesday, 27 December 2011 at 10:57:35 UTC, Peter Alexander 
wrote:

 On 27/12/11 10:51 AM, deadalnix wrote:

 Le 27/12/2011 05:25, Andrei Alexandrescu a écrit :

 https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc



 Andrei


 Maybe I'll seem bitter, but I do not think this changement was 
 really
 that important. This is nice, ok, but we have some other 
 really serious
 flaw, like shared not doing what it is supposed to do.


 You seem bitter :-)

 Seriously though, it's a fair point, but the syntax of lambdas 
 is fairly important and this appears to be a simple change so 
 the cost/benefit ratio is particularly high in this case.


This. You can let people play around with it, test it and provide 
feedback with just a small patch.

And it is indeed very important. It's one of the few syntax woes 
we have to deal with in D, it would be a shame to let the 
benefits of std.algorithm and any other functional D code be 
overshadowed by the powerful but often excessive syntax of 
anonymous functions.

It's important when presenting D to initiates that high-level 
code looks nice.
Dec 27 2011
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Tuesday, December 27, 2011 14:07:25 Jakob Ovrum wrote:

 And it is indeed very important. It's one of the few syntax woes
 we have to deal with in D, it would be a shame to let the
 benefits of std.algorithm and any other functional D code be
 overshadowed by the powerful but often excessive syntax of
 anonymous functions.


I find this sort of discussion to be somewhat funny. I don't think that it's a 
problem that D has added a new lambda syntax, but what we've had _so_ much 
better than C++ 98 that I never really cared. Sure, putting the return in 
there and all that is a bit verbose, but at least we have lambdas! I almost 
never use the algorithms in C++, because you have to define separate functors 
elsewhere. You don't even get nested functions! So, I've never seen much 
reason to complain about D's verbose lambda syntax, because it's so nice to 
have what we have rather than be forced to create functors and the like.

So, this is certainly a welcome change, but I've also found it kind of odd 
that some people have been complaining about it so much. Most of them probably 
aren't C++ programmers.

- Jonathan M Davis
Dec 27 2011
parent "foobar" <foo bar.com> writes:
On Wednesday, 28 December 2011 at 00:21:40 UTC, Jonathan M Davis 
wrote:

 On Tuesday, December 27, 2011 14:07:25 Jakob Ovrum wrote:

 And it is indeed very important. It's one of the few syntax 
 woes
 we have to deal with in D, it would be a shame to let the
 benefits of std.algorithm and any other functional D code be
 overshadowed by the powerful but often excessive syntax of
 anonymous functions.


 I find this sort of discussion to be somewhat funny. I don't 
 think that it's a problem that D has added a new lambda syntax, 
 but what we've had _so_ much better than C++ 98 that I never 
 really cared. Sure, putting the return in there and all that is 
 a bit verbose, but at least we have lambdas! I almost never use 
 the algorithms in C++, because you have to define separate 
 functors elsewhere. You don't even get nested functions! So, 
 I've never seen much reason to complain about D's verbose 
 lambda syntax, because it's so nice to have what we have rather 
 than be forced to create functors and the like.

 So, this is certainly a welcome change, but I've also found it 
 kind of odd that some people have been complaining about it so 
 much. Most of them probably aren't C++ programmers.

 - Jonathan M Davis


So your argument basically boils down to: "I find it funny that 
car owners (Non C++ programmers) complain about bicycles not 
being fast enough. I mean, it's way better than walking 
(Programming in C++)"

I fail to understand what's odd about that.
Dec 28 2011
prev sibling next sibling parent =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 27-12-2011 11:51, deadalnix wrote:

 Le 27/12/2011 05:25, Andrei Alexandrescu a écrit :

 https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc



 Andrei


 Maybe I'll seem bitter, but I do not think this changement was really
 that important. This is nice, ok, but we have some other really serious
 flaw, like shared not doing what it is supposed to do.


I don't quite agree. Short lambda syntax is *extremely important* for 
lambdas to actually be useful. If lambda syntax is not short and 
concise, it's not worth using over, say, a plain foreach loop.

I greatly welcome this change.

- Alex
Dec 27 2011
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/27/11 4:51 AM, deadalnix wrote:

 Le 27/12/2011 05:25, Andrei Alexandrescu a écrit :

 https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc



 Andrei


 Maybe I'll seem bitter, but I do not think this changement was really
 that important. This is nice, ok, but we have some other really serious
 flaw, like shared not doing what it is supposed to do.


Imagine how bitter I am that the string lambda syntax didn't catch on!

Andrei
Dec 27 2011
next sibling parent reply "dsimcha" <dsimcha yahoo.com> writes:
On Tuesday, 27 December 2011 at 15:11:25 UTC, Andrei Alexandrescu 
wrote:

 Imagine how bitter I am that the string lambda syntax didn't 
 catch on!

 Andrei


Please tell me they're not going anywhere.  I **really** don't 
want to deal with those being deprecated.
Dec 27 2011
parent reply "dsimcha" <dsimcha yahoo.com> writes:
On Tuesday, 27 December 2011 at 15:19:07 UTC, dsimcha wrote:

 On Tuesday, 27 December 2011 at 15:11:25 UTC, Andrei 
 Alexandrescu wrote:

 Imagine how bitter I am that the string lambda syntax didn't 
 catch on!

 Andrei


 Please tell me they're not going anywhere.  I **really** don't 
 want to deal with those being deprecated.


...and they were kind of useful in that you could introspect the 
string and apply optimizations depending on what the lambda was.  
I wrote a sorting function that introspected the lambda that was 
passed to it.  If it was "a < b", "a<b", "a > b", etc., and the 
array to be sorted was floating point, it punned and bit twiddled 
the floats/doubles to ints/longs, sorted them and bit twiddled 
and punned them back.
Dec 27 2011
parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/27/2011 7:21 AM, dsimcha wrote:

 On Tuesday, 27 December 2011 at 15:19:07 UTC, dsimcha wrote:

 On Tuesday, 27 December 2011 at 15:11:25 UTC, Andrei Alexandrescu wrote:

 Imagine how bitter I am that the string lambda syntax didn't catch on!

 Andrei


 Please tell me they're not going anywhere. I **really** don't want to deal
 with those being deprecated.


 ...and they were kind of useful in that you could introspect the string and
 apply optimizations depending on what the lambda was. I wrote a sorting
function
 that introspected the lambda that was passed to it. If it was "a < b", "a<b",
"a
  > b", etc., and the array to be sorted was floating point, it punned and bit
 twiddled the floats/doubles to ints/longs, sorted them and bit twiddled and
 punned them back.


It's not going anywhere, though it likely will disappear from the sample code.
Dec 27 2011
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/27/2011 7:11 AM, Andrei Alexandrescu wrote:

 Imagine how bitter I am that the string lambda syntax didn't catch on!


As I told Andrei last night, I think it was a great experiment. Sure, it
failed, 
but it was a great idea, technically sound, and the fact that it worked is a 
testament to D's power.

If we're not willing to try things like that, we've failed in a much grander
sense.

So I have no regrets at all about that.
Dec 27 2011
parent reply so <so so.so> writes:
On Tue, 27 Dec 2011 20:11:41 +0200, Walter Bright  
<newshound2 digitalmars.com> wrote:


 On 12/27/2011 7:11 AM, Andrei Alexandrescu wrote:

 Imagine how bitter I am that the string lambda syntax didn't catch on!


 As I told Andrei last night, I think it was a great experiment. Sure, it  
 failed, but it was a great idea, technically sound, and the fact that it  
 worked is a testament to D's power.

 If we're not willing to try things like that, we've failed in a much  
 grander sense.

 So I have no regrets at all about that.


If C++ or Java (or what have you) had support for string as template  
parameters,
string lambdas probably would be irreplaceable to many.

|"a % 2"|
|a => a % 2|

Still it is shorter.
Dec 27 2011
parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/27/2011 11:50 AM, so wrote:

 If C++ or Java (or what have you) had support for string as template
parameters,
 string lambdas probably would be irreplaceable to many.

 |"a % 2"|
 |a => a % 2|

 Still it is shorter.


I know.

Unfortunately, the C/C++ text preprocessor has left such a bad taste in
peoples' 
mouths that anything even remotely suggestive of it has an "ick" factor that it 
is hard to get past.
Dec 27 2011
prev sibling parent "Marco Leise" <Marco.Leise gmx.de> writes:
Am 27.12.2011, 16:11 Uhr, schrieb Andrei Alexandrescu  =

<SeeWebsiteForEmail erdani.org>:


 On 12/27/11 4:51 AM, deadalnix wrote:

 Le 27/12/2011 05:25, Andrei Alexandrescu a =C3=A9crit :

 https://github.com/D-Programming-Language/dmd/commit/675898721c04d0b=






f155a85abf986eae99c37c0dc

 Andrei


 Maybe I'll seem bitter, but I do not think this changement was really=





 that important. This is nice, ok, but we have some other really serio=




us

 flaw, like shared not doing what it is supposed to do.


 Imagine how bitter I am that the string lambda syntax didn't catch on!=



 Andrei


I used it and I am not sure if it had draw backs, but looking at the cod=
e  =

to support them, it gave me the feeling that you were doing part of the =
 =

job, the compiler should be doing: test if the alias is a string, if it =
 =

can be compiled and assigning variable names to parameters. I once adapt=
ed  =

that style to write something similar to binaryFun and the algorithm  =

templates. It worked for me after a while, but I found it a bit  =

complicated. (Before D, I only used templates as far as generic types go=
.)  =

The source code didn't *look* exactly concise and going with the languag=
e  =

to me, if you know what I mean. It shows a nice capability of the langua=
ge  =

- maybe the first time newbies stumble over mixin string, but a short  =

lambda syntax is as good (because the string mixin doesn't get us anythi=
ng  =

beyond that) and saves the if-else to identify the kind of alias and the=
  =

support code. Honestly, I never really liked the idea of string mixins f=
or  =

general use :D like saving on boilerplate code, multi-inheritance etc. I=
t  =

may seem odd, but I prefer a dozen language features over one string mix=
in  =

feature that can cover them all.
That brings me to another point: I like to use IDEs and they must have  =

difficulties in understanding string mixins and giving hints. There are =
no  =

rules to what you can put in a string, but a lambda syntax defined in th=
e  =

specification can be checked in the IDE.
Dec 28 2011
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/27/2011 2:51 AM, deadalnix wrote:

 Maybe I'll seem bitter, but I do not think this changement was really that
 important. This is nice, ok, but we have some other really serious flaw, like
 shared not doing what it is supposed to do.


Technically, it is not important at all. It adds zero power and functionality. 
All it is is a simple syntactical rewrite within the compiler to the old syntax.

However, and this is a big however, aesthetically it is a large improvement. 
People using many diverse languages have made it clear that this is the 
preferred syntax for lambdas. They expect to see it, or else they mark D as
"not 
having lambdas" and "not supporting functional programming".

Syntax matters.
Dec 27 2011
prev sibling next sibling parent reply =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 27-12-2011 05:25, Andrei Alexandrescu wrote:

 https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc


 Andrei


Awesome!

Now the only gripe I have left is type inference for lambdas passed as 
regular function parameters. Is this something we will see anytime soon?

- Alex
Dec 27 2011
next sibling parent reply =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 27-12-2011 15:19, Alex Rønne Petersen wrote:

 On 27-12-2011 05:25, Andrei Alexandrescu wrote:

 https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc



 Andrei


 Awesome!

 Now the only gripe I have left is type inference for lambdas passed as
 regular function parameters. Is this something we will see anytime soon?

 - Alex


Just to make it clear what I want to be able to do (simple example with 
arrays):

T[] filter(T)(T[] items, scope bool delegate(T) predicate)
{
     T[] newItems;

     foreach (item; items)
         if (predicate(item))
             newItems ~= item;

     return newItems;
}

auto ints = filter([0, 1, 2, 3, 4, 5], x => x % 2 != 0);

Or perhaps even better, when we get fully working UFCS:

auto ints = [0, 1, 2, 3, 4, 5].filter(x => x % 2 != 0);

DMD should be able to infer the parameter type(s) of the delegate I'm 
passing, since that's clear from the array being passed. (I would 

sophisticated for an imperative language.)

- Alex
Dec 27 2011
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Alex Rønne Petersen" <xtzgzorex gmail.com> wrote in message 
news:jdckl1$1hfb$1 digitalmars.com...

 Or perhaps even better, when we get fully working UFCS:

 auto ints = [0, 1, 2, 3, 4, 5].filter(x => x % 2 != 0);


That is just beautiful.
Dec 27 2011
next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Wouldn't it be great if Santa were to give us named arguments this year too? :)
Dec 27 2011
prev sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Tuesday, December 27, 2011 18:43:14 Andrej Mitrovic wrote:

 Wouldn't it be great if Santa were to give us named arguments this year too?
 :)


Only if he hates me. But I guess that I'm in the minority around here in that 
I hate the idea of named arguments.

- Jonathan M Davis
Dec 27 2011
parent reply "Marco Leise" <Marco.Leise gmx.de> writes:
Am 28.12.2011, 01:22 Uhr, schrieb Jonathan M Davis <jmdavisProg gmx.com>=
:


 On Tuesday, December 27, 2011 18:43:14 Andrej Mitrovic wrote:

 Wouldn't it be great if Santa were to give us named arguments this ye=




ar  =


 too?
 :)


 Only if he hates me. But I guess that I'm in the minority around here =


in  =


 that
 I hate the idea of named arguments.

 - Jonathan M Davis


Despite that feature being optional to use, I could understand you if yo=
u  =

think it only makes sense on obscure 'true'/'false' flags and prefer nam=
ed  =

enums there. Then there would be two ways to do the same thing, which  =

annoys language purists like me ^^.

(=E2=80=A6, overwrite =3D true); vs. (=E2=80=A6, CreateMode.overwrite);

But named parameters can do more, like skipping some optional parameters=
  =

and using others.

int foo(int a =3D 0, int b =3D 1, int c =3D 2) {}
foo(c =3D 3);
Dec 28 2011
next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
I can understand how Jonathan has no problem writing verbose code, but
I'd rather not have to write enums all over the place just to use a
true/false flag that is obvious at the call site compared to calls
like this:

showWidget(true, false);

But I bet one day Walter & Co. will have another phone conversation
and then magically we'll have named arguments the next day, without
asking the community about how it feels about the inclusion (e.g. just
like D1 deprecation, this lambda syntax, and other behind-the-scenes
decisions between Walter and Andrei). All it will take is probably an
angry Redditor or maybe some coworker at Facebook that asked for the
feature.

I'm just against decisions made between the two heads of state that
happen over night. I'd like a little more transparency from our "D
government", if you know what I mean. ;-)

Anyway this new lambda thing is sweet.
Dec 28 2011
next sibling parent reply Peter Alexander <peter.alexander.au gmail.com> writes:
On 28/12/11 2:57 PM, Andrej Mitrovic wrote:

 But I bet one day Walter&  Co. will have another phone conversation
 and then magically we'll have named arguments the next day, without
 asking the community about how it feels about the inclusion (e.g. just
 like D1 deprecation, this lambda syntax, and other behind-the-scenes
 decisions between Walter and Andrei). All it will take is probably an
 angry Redditor or maybe some coworker at Facebook that asked for the
 feature.

 I'm just against decisions made between the two heads of state that
 happen over night. I'd like a little more transparency from our "D
 government", if you know what I mean. ;-)


The lambda syntax was discussed at length with the community a while ago.
Dec 28 2011
parent Jacob Carlborg <doob me.com> writes:
On 2011-12-28 16:14, Peter Alexander wrote:

 On 28/12/11 2:57 PM, Andrej Mitrovic wrote:

 But I bet one day Walter& Co. will have another phone conversation
 and then magically we'll have named arguments the next day, without
 asking the community about how it feels about the inclusion (e.g. just
 like D1 deprecation, this lambda syntax, and other behind-the-scenes
 decisions between Walter and Andrei). All it will take is probably an
 angry Redditor or maybe some coworker at Facebook that asked for the
 feature.

 I'm just against decisions made between the two heads of state that
 happen over night. I'd like a little more transparency from our "D
 government", if you know what I mean. ;-)


 The lambda syntax was discussed at length with the community a while ago.


... and it was basically decided that it should be added to the language.

-- 
/Jacob Carlborg
Dec 28 2011
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/28/11 8:57 AM, Andrej Mitrovic wrote:

 I can understand how Jonathan has no problem writing verbose code, but
 I'd rather not have to write enums all over the place just to use a
 true/false flag that is obvious at the call site compared to calls
 like this:

 showWidget(true, false);

 But I bet one day Walter&  Co. will have another phone conversation
 and then magically we'll have named arguments the next day, without
 asking the community about how it feels about the inclusion (e.g. just
 like D1 deprecation, this lambda syntax, and other behind-the-scenes
 decisions between Walter and Andrei). All it will take is probably an
 angry Redditor or maybe some coworker at Facebook that asked for the
 feature.


Well as Peter said, this is a tad unfair. The decision on lambdas is a 
logical consequence of many months of discussing the issue back and 
forth across the community.

The decision to discontinue D1 could have been carried more elegantly, 
and I apologize for that. Nevertheless it would have been just as 
inevitable, and clearly it is doing and will continue to do a world of 
good to D. If anything I am sorry we didn't take the step earlier. 
Announcing a two-year expiration of D1 at the end of 2010 would have 
been even better.


 I'm just against decisions made between the two heads of state that
 happen over night. I'd like a little more transparency from our "D
 government", if you know what I mean. ;-)


Roger that. Also, I'm not sure if you were around - things did improve 
quite a bit compared to a while ago.


Andrei
Dec 28 2011
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-12-28 14:18, Marco Leise wrote:

 Am 28.12.2011, 01:22 Uhr, schrieb Jonathan M Davis <jmdavisProg gmx.com>:


 On Tuesday, December 27, 2011 18:43:14 Andrej Mitrovic wrote:

 Wouldn't it be great if Santa were to give us named arguments this
 year too?
 :)


 Only if he hates me. But I guess that I'm in the minority around here
 in that
 I hate the idea of named arguments.

 - Jonathan M Davis


 Despite that feature being optional to use, I could understand you if
 you think it only makes sense on obscure 'true'/'false' flags and prefer
 named enums there. Then there would be two ways to do the same thing,
 which annoys language purists like me ^^.

 (
, overwrite = true); vs. (
, CreateMode.overwrite);

 But named parameters can do more, like skipping some optional parameters
 and using others.

 int foo(int a = 0, int b = 1, int c = 2) {}
 foo(c = 3);



optional arguments it became a lot easier to use COM functions:

http://msdn.microsoft.com/en-us/library/dd264739.aspx

-- 
/Jacob Carlborg
Dec 28 2011
prev sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, December 28, 2011 15:57:42 Andrej Mitrovic wrote:

 I can understand how Jonathan has no problem writing verbose code, but
 I'd rather not have to write enums all over the place just to use a
 true/false flag that is obvious at the call site compared to calls
 like this:
 
 showWidget(true, false);


I'm not a big fan of the enum's for true/false either. I have no problem 
whatsoever with the above line of code. I'd much rather have that than named 
arguments.

The primary reason that I really don't like named arguments is the fact that 
the names of the parameters become part of the API. I also don't think that 
they add much unless you have functions with way too many parameters, and 
those sorts of functions shouldn't be happening anyway. And I don't like the 
additional complication of the possibility of reordering functiion arguments. 
You should be able to look at a function and know which parameters its 
arguments go with purely by the order, which named arguments destroy.

But all of that has been discussed at length before. I'm completely opposed to 
the idea, but I seem to be in the minority (at least out of those who spoke 
up).

- Jonathan M Davis
Dec 28 2011
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 12/28/2011 09:25 PM, Jonathan M Davis wrote:

 On Wednesday, December 28, 2011 15:57:42 Andrej Mitrovic wrote:

 I can understand how Jonathan has no problem writing verbose code, but
 I'd rather not have to write enums all over the place just to use a
 true/false flag that is obvious at the call site compared to calls
 like this:

 showWidget(true, false);


 I'm not a big fan of the enum's for true/false either. I have no problem
 whatsoever with the above line of code. I'd much rather have that than named
 arguments.

 The primary reason that I really don't like named arguments is the fact that
 the names of the parameters become part of the API.


That assumes every parameter is implicitly named. If named arguments 
ever get into the language, then they should imho be marked as named 
arguments explicitly at function declaration point.


 I also don't think that they add much unless you have functions with way too
many parameters, and
 those sorts of functions shouldn't be happening anyway. And I don't like the
 additional complication of the possibility of reordering functiion arguments.
 You should be able to look at a function and know which parameters its
 arguments go with purely by the order, which named arguments destroy.


Why would that be beneficial?


 But all of that has been discussed at length before. I'm completely opposed to
 the idea, but I seem to be in the minority (at least out of those who spoke
 up).

 - Jonathan M Davis


I don't need named arguments either, but I don't think they would hurt 
if implemented as a purely optional feature.
Dec 28 2011
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, December 28, 2011 21:44:01 Timon Gehr wrote:

 I also don't think that they add much unless you have functions with way
 too many parameters, and those sorts of functions shouldn't be
 happening anyway. And I don't like the additional complication of the
 possibility of reordering functiion arguments. You should be able to
 look at a function and know which parameters its arguments go with
 purely by the order, which named arguments destroy.


 Why would that be beneficial?


I'd hate to have a function like

void func(float x, float y);

where calling it

func(1.0, 2.0);

and

func(y : 1.0, x : 2.0);

don't do the same thing. All of a sudden, I have to pay attention to what 
names the arguments were given. I can't just read the function call like I 
would now. It becomes error-prone in that regard and violates the current 
expectations of argument order. It will make code harder to read for minimal 
benefit IMHO. I do _not_ think that name arguments are an improvement.


 But all of that has been discussed at length before. I'm completely
 opposed to the idea, but I seem to be in the minority (at least out of
 those who spoke up).
 
 - Jonathan M Davis


 
 I don't need named arguments either, but I don't think they would hurt
 if implemented as a purely optional feature.


Since they affect the API, they _do_ hurt. Since then any changes to parameter 
names break code. So, it has a definite affect on code maintainibility even if
I 
don't use the feature myself. I also don't want to see them in code. If the 
example above were possible, then someone would use it in their code (even if 
I didn't), and I'd have to deal with all of the code readibility issues that 
it causes. Named arguments _would_ hurt the language even if they were purely 
optional.

- Jonathan M Davis
Dec 28 2011
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 12/28/2011 09:57 PM, Jonathan M Davis wrote:

 On Wednesday, December 28, 2011 21:44:01 Timon Gehr wrote:

 I also don't think that they add much unless you have functions with way
 too many parameters, and those sorts of functions shouldn't be
 happening anyway. And I don't like the additional complication of the
 possibility of reordering functiion arguments. You should be able to
 look at a function and know which parameters its arguments go with
 purely by the order, which named arguments destroy.


 Why would that be beneficial?


 I'd hate to have a function like

 void func(float x, float y);

 where calling it

 func(1.0, 2.0);

 and

 func(y : 1.0, x : 2.0);

 don't do the same thing. All of a sudden, I have to pay attention to what
 names the arguments were given.  I can't just read the function call like I
 would now. It becomes error-prone in that regard and violates the current
 expectations of argument order.  It will make code harder to read for minimal
 benefit IMHO. I do _not_ think that name arguments are an improvement.


So it is the usual "because the feature can be misused it is bad" argument?


 But all of that has been discussed at length before. I'm completely
 opposed to the idea, but I seem to be in the minority (at least out of
 those who spoke up).

 - Jonathan M Davis


 I don't need named arguments either, but I don't think they would hurt
 if implemented as a purely optional feature.


 Since they affect the API, they _do_ hurt. Since then any changes to parameter
 names break code. So, it has a definite affect on code maintainibility even if
I
 don't use the feature myself. I also don't want to see them in code. If the
 example above were possible, then someone would use it in their code (even if
 I didn't), and I'd have to deal with all of the code readibility issues that
 it causes. Named arguments _would_ hurt the language even if they were purely
 optional.

 - Jonathan M Davis


That is not what I'd call purely optional.

Timon Gehr wrote:

 That assumes every parameter is implicitly named. If named arguments ever get
 into the language, then they should imho be marked as named arguments
explicitly
 at function declaration point.
Dec 28 2011
prev sibling next sibling parent reply so <so so.so> writes:
On Wed, 28 Dec 2011 22:57:32 +0200, Jonathan M Davis <jmdavisProg gmx.com>  
wrote:


 I'd hate to have a function like

 void func(float x, float y);

 where calling it

 func(1.0, 2.0);

 and

 func(y : 1.0, x : 2.0);

 don't do the same thing. All of a sudden, I have to pay attention to what
 names the arguments were given. I can't just read the function call like  
 I
 would now. It becomes error-prone in that regard and violates the current
 expectations of argument order. It will make code harder to read for  
 minimal
 benefit IMHO. I do _not_ think that name arguments are an improvement.


Are you aware all the points you made support the need for named arguments  
rather than what you were trying to achieve?
Named parameter fixed a bug in your code and you are trying to explain how  
crap a feature is NP? :)

If you are "trying" to read a function call when it uses named parameters,  
its not the fault of the feature but its implementation in given language.
For this reason i kept saying we shouldn't inherit it from other languages  
but keep it simple.
The feature supposed to ease the reading of a function call and enforce  
some guarantees.


 But all of that has been discussed at length before. I'm completely
 opposed to the idea, but I seem to be in the minority (at least out of
 those who spoke up).

 - Jonathan M Davis


 I don't need named arguments either, but I don't think they would hurt
 if implemented as a purely optional feature.


 Since they affect the API, they _do_ hurt. Since then any changes to  
 parameter
 names break code. So, it has a definite affect on code maintainibility  
 even if I
 don't use the feature myself. I also don't want to see them in code. If  
 the
 example above were possible, then someone would use it in their code  
 (even if
 I didn't), and I'd have to deal with all of the code readibility issues  
 that
 it causes. Named arguments _would_ hurt the language even if they were  
 purely
 optional.


It doesn't create readability issues, it is there to solve them.
Maintainability issues? How?
If you change "anything" in your interface, it is already a breaking  
change.
Dec 28 2011
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 12/28/2011 11:34 PM, so wrote:

 If you change "anything" in your interface, it is already a breaking
 change.


That is why it is desirable to not let parameter names contribute to the 
interface. Jonathan definitely has a point against making all parameters 
named parameters by default.

 From a recent thread in D.learn:

Christophe wrote:

 Timon Gehr wrote:

 but the drawback is that the parameter names become part of the
 public interface.


 Well, that's precisely the point. And it is a drawback if parameters are
 systematically names, but not if it is triggered only on demand.

 Example :

 void foo(int a, int b:, int c:);

 void main() {
 	foo(1, 2, 3);
 	foo(1, c: 3, b: 2;
 	foo(a: 1, b: 2, c: 3); // error : a is not a named parameter.
 }

 In the example, ":" is used to make a named parameter to recall the use
 when you call the function.


I thought that was pretty convincing.
Dec 28 2011
parent reply so <so so.so> writes:
On Thu, 29 Dec 2011 00:48:54 +0200, Timon Gehr <timon.gehr gmx.ch> wrote:


 On 12/28/2011 11:34 PM, so wrote:

 If you change "anything" in your interface, it is already a breaking
 change.


 That is why it is desirable to not let parameter names contribute to the  
 interface. Jonathan definitely has a point against making all parameters  
 named parameters by default.


/// A.d
void fun1(int Arg);
void fun2(int x);

/// B.d
void fun1(int arg);
void fun2(int y);

I am having hard time understanding the issue really.
Now as a user i don't know why the library dev. changed the interface:

/// without NP
fun1(arg); // recompile no edit,
fun2(x);   // well

You are saying like changing a parameter name in lib code is always so  
harmless.
You guys making your case on a dumb developer that goes for a breaking  
change just to fix a always harmless typo.
Then, what makes you so sure he won't do this?
Dec 28 2011
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 12/29/2011 12:29 AM, so wrote:

 On Thu, 29 Dec 2011 00:48:54 +0200, Timon Gehr <timon.gehr gmx.ch> wrote:


 On 12/28/2011 11:34 PM, so wrote:

 If you change "anything" in your interface, it is already a breaking
 change.


 That is why it is desirable to not let parameter names contribute to
 the interface. Jonathan definitely has a point against making all
 parameters named parameters by default.


 /// A.d
 void fun1(int Arg);
 void fun2(int x);

 /// B.d
 void fun1(int arg);
 void fun2(int y);

 I am having hard time understanding the issue really.
 Now as a user i don't know why the library dev. changed the interface:

 /// without NP
 fun1(arg); // recompile no edit,
 fun2(x); // well

 You are saying like changing a parameter name in lib code is always so
 harmless.
 You guys making your case on a dumb developer that goes for a breaking
 change just to fix a always harmless typo.


I have a hard time understanding your case. You wrote /// without NP. 
Without NP it is perfectly reasonable to fix the typo and there is no 
breaking change. That is part of why having no NP by default is 
desirable. The moment NP by default is introduced is the moment all 
parameter names in all libraries are set in stone. Those names were mere 
implementation details prior to that point in time.
Having parameter names contribute to the interface means that all 
developers need to spend time thinking about the best possible names for 
their function parameters.


 Then, what makes you so sure he won't do this?


What makes you so sure that if he does, he actually remembers to change 
the functionality too?
Dec 28 2011
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Timon Gehr:


 Having parameter names contribute to the interface means that all 
 developers need to spend time thinking about the best possible names for 
 their function parameters.


And this is a good thing :-) It helps you understand the function purpose
better.

Bye,
bearophile
Dec 28 2011
prev sibling next sibling parent reply so <so so.so> writes:
On Thu, 29 Dec 2011 01:48:57 +0200, Timon Gehr <timon.gehr gmx.ch> wrote:


 The moment NP by default is introduced is the moment all parameter names  
 in all libraries are set in stone.


This is completely false. NP affects only those that "want" to use it, no  
one else. Again, no one.
It is just like inline asm.


 Those names were mere implementation details prior to that point in time.
 Having parameter names contribute to the interface means that all  
 developers need to spend time thinking about the best possible names for  
 their function parameters.


 Then, what makes you so sure he won't do this?


 What makes you so sure that if he does, he actually remembers to change  
 the functionality too?


You are not making any sense here i am sorry.
Read the examples.

He doesn't need to remember, compiler does that for him but only for him :)
Dec 28 2011
next sibling parent so <so so.so> writes:
On Thu, 29 Dec 2011 01:58:46 +0200, so <so so.so> wrote:


 He doesn't need to remember, compiler does that for him but only for him  
 :)


As it turns out compiler don't give a damn about him either.
Dec 28 2011
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 12/29/2011 12:58 AM, so wrote:

 On Thu, 29 Dec 2011 01:48:57 +0200, Timon Gehr <timon.gehr gmx.ch> wrote:


 The moment NP by default is introduced is the moment all parameter
 names in all libraries are set in stone.


 This is completely false. NP affects only those that "want" to use it,
 no one else. Again, no one.
 It is just like inline asm.


No, it is not. If all parameters are named parameters, then the library 
writers have to be aware of the fact that some users might use named 
arguments. Again, every library writer is affected.


 Those names were mere implementation details prior to that point in time.
 Having parameter names contribute to the interface means that all
 developers need to spend time thinking about the best possible names
 for their function parameters.


 Then, what makes you so sure he won't do this?


 What makes you so sure that if he does, he actually remembers to
 change the functionality too?


 You are not making any sense here i am sorry.


That was the point. I was continuing the reasoning in your previous post.
Dec 28 2011
parent reply so <so so.so> writes:
On Thu, 29 Dec 2011 02:14:18 +0200, Timon Gehr <timon.gehr gmx.ch> wrote:


 On 12/29/2011 12:58 AM, so wrote:

 On Thu, 29 Dec 2011 01:48:57 +0200, Timon Gehr <timon.gehr gmx.ch>  
 wrote:


 The moment NP by default is introduced is the moment all parameter
 names in all libraries are set in stone.


 This is completely false. NP affects only those that "want" to use it,
 no one else. Again, no one.
 It is just like inline asm.


 No, it is not. If all parameters are named parameters, then the library  
 writers have to be aware of the fact that some users might use named  
 arguments. Again, every library writer is affected.


Show me any library code from any language where library writer is not  
already "aware" their argument names define their function.
They even document it that way.

/// a does this, b does that
void fun(int a, int b)
Dec 28 2011
next sibling parent Derek <ddparnell bigpond.com> writes:
On Thu, 29 Dec 2011 12:02:28 +1100, so <so so.so> wrote:


 Show me any library code from any language where library writer is not  
 already "aware" their argument names define their function.


Supporting example:

    int find( T needle, T[] haystack)



As a side effect, it might even help prevent the unnecessary use of  
one-character parameter names, LOL.

-- 
Derek Parnell
Melbourne, Australia
Dec 28 2011
prev sibling next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 12/29/2011 02:02 AM, so wrote:

 On Thu, 29 Dec 2011 02:14:18 +0200, Timon Gehr <timon.gehr gmx.ch> wrote:


 On 12/29/2011 12:58 AM, so wrote:

 On Thu, 29 Dec 2011 01:48:57 +0200, Timon Gehr <timon.gehr gmx.ch>
 wrote:


 The moment NP by default is introduced is the moment all parameter
 names in all libraries are set in stone.


 This is completely false. NP affects only those that "want" to use it,
 no one else. Again, no one.
 It is just like inline asm.


 No, it is not. If all parameters are named parameters, then the
 library writers have to be aware of the fact that some users might use
 named arguments. Again, every library writer is affected.


 Show me any library code from any language where library writer is not
 already "aware" their argument names define their function.
 They even document it that way.

 /// a does this, b does that
 void fun(int a, int b)


Documentation can be improved over time.
It cannot be argued that the widening of the set of exposed names is a 
positive aspect of named arguments.
Dec 28 2011
prev sibling parent reply Don <nospam nospam.com> writes:
On 29.12.2011 02:02, so wrote:

 On Thu, 29 Dec 2011 02:14:18 +0200, Timon Gehr <timon.gehr gmx.ch> wrote:


 On 12/29/2011 12:58 AM, so wrote:

 On Thu, 29 Dec 2011 01:48:57 +0200, Timon Gehr <timon.gehr gmx.ch>
 wrote:


 The moment NP by default is introduced is the moment all parameter
 names in all libraries are set in stone.


 This is completely false. NP affects only those that "want" to use it,
 no one else. Again, no one.
 It is just like inline asm.


 No, it is not. If all parameters are named parameters, then the
 library writers have to be aware of the fact that some users might use
 named arguments. Again, every library writer is affected.


 Show me any library code from any language where library writer is not
 already "aware" their argument names define their function.
 They even document it that way.

 /// a does this, b does that
 void fun(int a, int b)


sin(real x);
sin(real theta);

The argument name is *completely* irrelevant. That shouldn't be part of 
the interface.

I have a really really bad taste in my mouth from named arguments in COM.
Dec 29 2011
next sibling parent reply Derek <ddparnell bigpond.com> writes:
On Thu, 29 Dec 2011 19:07:17 +1100, Don <nospam nospam.com> wrote:



 sin(real x);
 sin(real theta);

 The argument name is *completely* irrelevant. That shouldn't be part of  
 the interface.

 I have a really really bad taste in my mouth from named arguments in COM.


Were you forced to use named parameters or was it optional?

-- 
Derek Parnell
Melbourne, Australia
Dec 29 2011
parent Don <nospam nospam.com> writes:
On 29.12.2011 09:34, Derek wrote:

 On Thu, 29 Dec 2011 19:07:17 +1100, Don <nospam nospam.com> wrote:



 sin(real x);
 sin(real theta);

 The argument name is *completely* irrelevant. That shouldn't be part
 of the interface.

 I have a really really bad taste in my mouth from named arguments in COM.


 Were you forced to use named parameters or was it optional?


Forced to support them. The great evil is that the named arguments can 
arrive in any order.

You're not forced to use them. It's just for the benefit of VB.
Dec 29 2011
prev sibling parent reply Mehrdad <wfunction hotmail.com> writes:
On 12/29/2011 3:07 AM, Don wrote:

 sin(real x);
 sin(real theta);

 The argument name is *completely* irrelevant. That shouldn't be part 
 of the interface.

 I have a really really bad taste in my mouth from named arguments in COM.


Great example... I can totally think that 'x', 'theta', 't', 'angle', 
'radians', 'value', 'val', 'v', etc. could all be valid parameter names 
(some better than others, obviously).
Dec 29 2011
parent reply Derek <ddparnell bigpond.com> writes:
On Fri, 30 Dec 2011 01:16:56 +1100, Mehrdad <wfunction hotmail.com> wrote:


 On 12/29/2011 3:07 AM, Don wrote:

 sin(real x);
 sin(real theta);

 The argument name is *completely* irrelevant. That shouldn't be part of  
 the interface.

 I have a really really bad taste in my mouth from named arguments in  
 COM.


 Great example... I can totally think that 'x', 'theta', 't', 'angle',  
 'radians', 'value', 'val', 'v', etc. could all be valid parameter names  
 (some better than others, obviously).


I'm not so convinced ...

   sin(real elephant);

   set_color( int JohnSmith, int penis, int dictionary);


Actually, names do matter.

-- 
Derek Parnell
Melbourne, Australia
Dec 29 2011
parent reply Don <nospam nospam.com> writes:
On 29.12.2011 23:00, Derek wrote:

 On Fri, 30 Dec 2011 01:16:56 +1100, Mehrdad <wfunction hotmail.com> wrote:


 On 12/29/2011 3:07 AM, Don wrote:

 sin(real x);
 sin(real theta);

 The argument name is *completely* irrelevant. That shouldn't be part
 of the interface.

 I have a really really bad taste in my mouth from named arguments in
 COM.


 Great example... I can totally think that 'x', 'theta', 't', 'angle',
 'radians', 'value', 'val', 'v', etc. could all be valid parameter
 names (some better than others, obviously).


 I'm not so convinced ...

 sin(real elephant);

 set_color( int JohnSmith, int penis, int dictionary);


 Actually, names do matter.


Some names are better than others. But are they part of the API? That's 
the issue.
Often, parameter names (such as in sin(x)) are arbitrary and 
meaningless. This is fundamental: the parameter names are arbitrary in 
mathematics.
Dec 29 2011
parent reply Derek <ddparnell bigpond.com> writes:
On Fri, 30 Dec 2011 16:22:49 +1100, Don <nospam nospam.com> wrote:



 Some names are better than others. But are they part of the API? That's  
 the issue.


Yes, that is an issue.


 Often, parameter names (such as in sin(x)) are arbitrary and  
 meaningless. This is fundamental: the parameter names are arbitrary in  
 mathematics.


Why is that? I just assumed that it was because mathematicians did a lot  
of repetitive handwriting and thus brevity was important to them.

-- 
Derek Parnell
Melbourne, Australia
Dec 29 2011
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/30/11 12:25 AM, Derek wrote:

 On Fri, 30 Dec 2011 16:22:49 +1100, Don <nospam nospam.com> wrote:



 Some names are better than others. But are they part of the API?
 That's the issue.


 Yes, that is an issue.


 Often, parameter names (such as in sin(x)) are arbitrary and
 meaningless. This is fundamental: the parameter names are arbitrary in
 mathematics.


 Why is that? I just assumed that it was because mathematicians did a lot
 of repetitive handwriting and thus brevity was important to them.


Well one non-partisan opinion (in any direction) is I've recently played 
with e.g. Python's POpen 
(http://docs.python.org/library/subprocess.html#subprocess.Popen). It's 
quite comfy to be able to say stdout=somefile, stderr=somefile instead 
of enumerating arguments and relying on order to make them sensible.

Using such functions is not math, but is part of writing programs.


Andrei
Dec 29 2011
next sibling parent Manfred Nowak <svv1999 hotmail.com> writes:
Andrei Alexandrescu wrote:


 is part of writing programs


If libraries from more than one author are used with named parameters, 
inconsistencies in the naming will be a normal problem.

For example: a boolean parameter for generating ouput might be named 
differently in two libraries as `print' (aka C) or `doWrite' (aka D).

Another: Directions in two dimensions be named `up, down, left, right' or 
`north, south, west, east'. 

Of course the positions for such parameters are also not fixed.

BTW: those who really want named (optional) parameters can already define 
their own,as   Gor pointed out in digitalmars.D:153790. The expenditures at 
the call are minimal, i.e `([' parantheses and restating the name of the 
function for every parameter:

|    f([ f.g= 1, f.h= 2 ]);  

-manfred
Dec 30 2011
prev sibling parent reply Don <nospam nospam.com> writes:
On 30.12.2011 07:36, Andrei Alexandrescu wrote:

 On 12/30/11 12:25 AM, Derek wrote:

 On Fri, 30 Dec 2011 16:22:49 +1100, Don <nospam nospam.com> wrote:



 Some names are better than others. But are they part of the API?
 That's the issue.


 Yes, that is an issue.


 Often, parameter names (such as in sin(x)) are arbitrary and
 meaningless. This is fundamental: the parameter names are arbitrary in
 mathematics.


 Why is that? I just assumed that it was because mathematicians did a lot
 of repetitive handwriting and thus brevity was important to them.


 Well one non-partisan opinion (in any direction) is I've recently played
 with e.g. Python's POpen
 (http://docs.python.org/library/subprocess.html#subprocess.Popen). It's
 quite comfy to be able to say stdout=somefile, stderr=somefile instead
 of enumerating arguments and relying on order to make them sensible.

 Using such functions is not math, but is part of writing programs.


There are definitely cases when you can create a much nicer API, when 
you can use named parameters. This is particularly true of flags, and 
where there are default parameters.
But I think that (a) it's not _all_ functions; and (b) you probably want 
to use named parameters consistently. I think it would be poor form to 
write these two lines in the same module:

  Popen(args, None, None, somefile, somefile);
  Popen(args, stdout : somefile, stderr : somefile);

so in the particular example of Popen, I think *requiring* all those 
parameters to be named in all calls wouldn't be a bad thing. Dunno if 
that's true in general though.

Note that in C/C++ you can easily create a header file where the 
parameters aren't named. But that isn't really available in D.
So there isn't even an opt-out mechanism.

I think: there are cases when named parameters are beneficial. There are 
cases where they are detrimental.
Is it possible to get the first, without the second, and without much 
complexity?
(I'm thinking of something like, a colon before the parameter name means 
the name is part of the API).
Dec 30 2011
parent reply so <so so.so> writes:
On Sat, 31 Dec 2011 02:40:24 +0200, Don <nospam nospam.com> wrote:


 I think: there are cases when named parameters are beneficial. There are  
 cases where they are detrimental.
 Is it possible to get the first, without the second, and without much  
 complexity?


If we keep rules simple as possible i think it is possible.
For that we need our own rules i think, remembering all those rules  
suggested here
i can understand why people have issues with them.


 (I'm thinking of something like, a colon before the parameter name means  
 the name is part of the API).


This i don't like, we shouldn't change anything on API side.
All they need to know is that their parameter names (if they provid one)  
might be used in NPs.
Otherwise it would complicate both implementation and usability.
Dec 30 2011
parent reply Don <nospam nospam.com> writes:
On 31.12.2011 02:27, so wrote:

 On Sat, 31 Dec 2011 02:40:24 +0200, Don <nospam nospam.com> wrote:


 I think: there are cases when named parameters are beneficial. There
 are cases where they are detrimental.
 Is it possible to get the first, without the second, and without much
 complexity?


 If we keep rules simple as possible i think it is possible.
 For that we need our own rules i think, remembering all those rules
 suggested here
 i can understand why people have issues with them.


 (I'm thinking of something like, a colon before the parameter name
 means the name is part of the API).


 This i don't like, we shouldn't change anything on API side.
 All they need to know is that their parameter names (if they provid one)
 might be used in NPs.
 Otherwise it would complicate both implementation and usability.


But it is IMPOSSIBLE to not provide them.
Dec 31 2011
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 12/31/2011 12:13 PM, Don wrote:

 On 31.12.2011 02:27, so wrote:

 On Sat, 31 Dec 2011 02:40:24 +0200, Don <nospam nospam.com> wrote:


 I think: there are cases when named parameters are beneficial. There
 are cases where they are detrimental.
 Is it possible to get the first, without the second, and without much
 complexity?


 If we keep rules simple as possible i think it is possible.
 For that we need our own rules i think, remembering all those rules
 suggested here
 i can understand why people have issues with them.


 (I'm thinking of something like, a colon before the parameter name
 means the name is part of the API).


 This i don't like, we shouldn't change anything on API side.
 All they need to know is that their parameter names (if they provid one)
 might be used in NPs.
 Otherwise it would complicate both implementation and usability.


 But it is IMPOSSIBLE to not provide them.


It is possible:

void foo(int, float, double, string);

But then it is impossible to have an implementation around for CTFE.
Dec 31 2011
parent reply Don <nospam nospam.com> writes:
On 31.12.2011 16:26, Timon Gehr wrote:

 On 12/31/2011 12:13 PM, Don wrote:

 On 31.12.2011 02:27, so wrote:

 On Sat, 31 Dec 2011 02:40:24 +0200, Don <nospam nospam.com> wrote:


 I think: there are cases when named parameters are beneficial. There
 are cases where they are detrimental.
 Is it possible to get the first, without the second, and without much
 complexity?


 If we keep rules simple as possible i think it is possible.
 For that we need our own rules i think, remembering all those rules
 suggested here
 i can understand why people have issues with them.


 (I'm thinking of something like, a colon before the parameter name
 means the name is part of the API).


 This i don't like, we shouldn't change anything on API side.
 All they need to know is that their parameter names (if they provid one)
 might be used in NPs.
 Otherwise it would complicate both implementation and usability.


 But it is IMPOSSIBLE to not provide them.


 It is possible:

 void foo(int, float, double, string);


Only if you create and hand-edit a .di file.
And that won't even work for templates.


 But then it is impossible to have an implementation around for CTFE.
Dec 31 2011
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 01/01/2012 08:17 AM, Don wrote:

 On 31.12.2011 16:26, Timon Gehr wrote:

 On 12/31/2011 12:13 PM, Don wrote:

 On 31.12.2011 02:27, so wrote:

 On Sat, 31 Dec 2011 02:40:24 +0200, Don <nospam nospam.com> wrote:


 I think: there are cases when named parameters are beneficial. There
 are cases where they are detrimental.
 Is it possible to get the first, without the second, and without much
 complexity?


 If we keep rules simple as possible i think it is possible.
 For that we need our own rules i think, remembering all those rules
 suggested here
 i can understand why people have issues with them.


 (I'm thinking of something like, a colon before the parameter name
 means the name is part of the API).


 This i don't like, we shouldn't change anything on API side.
 All they need to know is that their parameter names (if they provid
 one)
 might be used in NPs.
 Otherwise it would complicate both implementation and usability.


 But it is IMPOSSIBLE to not provide them.


 It is possible:

 void foo(int, float, double, string);


 Only if you create and hand-edit a .di file.
 And that won't even work for templates.


void foo(T...)(T _);

Then you have to manually reproduce overloading rules inside the 
template body. But you are right. There is no satisfactory solution.


 But then it is impossible to have an implementation around for CTFE.
Jan 01 2012
prev sibling parent reply Derek <ddparnell bigpond.com> writes:
On Thu, 29 Dec 2011 10:48:57 +1100, Timon Gehr <timon.gehr gmx.ch> wrote:


 Having parameter names contribute to the interface means that all  
 developers need to spend time thinking about the best possible names for  
 their function parameters.


And that's a bad thing, right?

Named parameters do have the issue that once released, it is can be costly  
to change the names. It therefore is important that library developers  
take enough time to consider parameter names, much in the same manner as  
they are currently consider existing exposed names.

To assist those developers, a name deprecation facility could be  
introduced to alert users of pending removal of old names. This would of  
course only be of interest to those developers who choose to use named  
parameters in their code.

There is a similar issue with positional parameters; once released, the  
library developer would be unwise to alter the order of parameters. But  
somehow, we have managed to educate ourselves so as to (mostly) avoid this  
problem.


In general, I'd support optional named parameters and would encourage  
their usage in those situations where it makes source code more  
understandable to other readers.

-- 
Derek Parnell
Melbourne, Australia
Dec 28 2011
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 12/29/2011 02:04 AM, Derek wrote:

 On Thu, 29 Dec 2011 10:48:57 +1100, Timon Gehr <timon.gehr gmx.ch> wrote:


 Having parameter names contribute to the interface means that all
 developers need to spend time thinking about the best possible names
 for their function parameters.


 And that's a bad thing, right?


If the time was better spent at creating functionality, yes.

http://www.digitalmars.com/d/archives/digitalmars/D/Rename_std.string.toStringz_138740.html

http://www.digitalmars.com/d/archives/digitalmars/D/Fixing_enum_names_in_Phobos_141507.html

http://www.digitalmars.com/d/archives/digitalmars/D/std.getopt_suggestion_145648.html#N145648

http://www.digitalmars.com/d/archives/digitalmars/D/renamepalooza_time_127446.html

...
etc.



 Named parameters do have the issue that once released, it is can be
 costly to change the names. It therefore is important that library
 developers take enough time to consider parameter names, much in the
 same manner as they are currently consider existing exposed names.

 To assist those developers, a name deprecation facility could be
 introduced to alert users of pending removal of old names. This would of
 course only be of interest to those developers who choose to use named
 parameters in their code.

 There is a similar issue with positional parameters; once released, the
 library developer would be unwise to alter the order of parameters. But
 somehow, we have managed to educate ourselves so as to (mostly) avoid
 this problem.


 In general, I'd support optional named parameters and would encourage
 their usage in those situations where it makes source code more
 understandable to other readers.


I am indifferent whether or not to add them.
Dec 28 2011
parent reply bearophile <bearophileHUGS lycos.com> writes:
Timon Gehr:


 On 12/29/2011 02:04 AM, Derek wrote:

 On Thu, 29 Dec 2011 10:48:57 +1100, Timon Gehr <timon.gehr gmx.ch> wrote:


 Having parameter names contribute to the interface means that all
 developers need to spend time thinking about the best possible names
 for their function parameters.


 And that's a bad thing, right?


 
 If the time was better spent at creating functionality, yes.
 
 http://www.digitalmars.com/d/archives/digitalmars/D/Rename_std.string.toStringz_138740.html
 
 http://www.digitalmars.com/d/archives/digitalmars/D/Fixing_enum_names_in_Phobos_141507.html
 
 http://www.digitalmars.com/d/archives/digitalmars/D/std.getopt_suggestion_145648.html#N145648
 
 http://www.digitalmars.com/d/archives/digitalmars/D/renamepalooza_time_127446.html


I don't agree. Names are among the most important things in a human mind, if
you find the right names, API usability improves. Thinking about the best names
is time well spent, especially for library functions used by a lot of all kind
of people for a lot of time.

Bye,
bearophile
Dec 28 2011
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 12/29/2011 03:38 AM, bearophile wrote:

 Timon Gehr:


 On 12/29/2011 02:04 AM, Derek wrote:

 On Thu, 29 Dec 2011 10:48:57 +1100, Timon Gehr<timon.gehr gmx.ch>  wrote:


 Having parameter names contribute to the interface means that all
 developers need to spend time thinking about the best possible names
 for their function parameters.


 And that's a bad thing, right?


 If the time was better spent at creating functionality, yes.

 http://www.digitalmars.com/d/archives/digitalmars/D/Rename_std.string.toStringz_138740.html

 http://www.digitalmars.com/d/archives/digitalmars/D/Fixing_enum_names_in_Phobos_141507.html

 http://www.digitalmars.com/d/archives/digitalmars/D/std.getopt_suggestion_145648.html#N145648

 http://www.digitalmars.com/d/archives/digitalmars/D/renamepalooza_time_127446.html


 I don't agree. Names are among the most important things in a human mind, if
you find the right names, API usability improves. Thinking about the best names
is time well spent, especially for library functions used by a lot of all kind
of people for a lot of time.

 Bye,
 bearophile


My point is, without named arguments you can improve the names at any 
time. With named arguments, you are stuck and have to get it right upfront.
Dec 28 2011
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Timon Gehr:


 My point is, without named arguments you can improve the names at any 
 time. With named arguments, you are stuck and have to get it right upfront.


I think library code doesn't change argument names often, and when this happens
I have suggested a way to deprecate argument names. Somehow Scala and Ada
programmers survive to that :-)

Bye,
bearophile
Dec 28 2011
prev sibling parent reply David Nadlinger <see klickverbot.at> writes:
On 12/29/11 3:46 AM, Timon Gehr wrote:

 My point is, without named arguments you can improve the names at any
 time. With named arguments, you are stuck and have to get it right upfront.


My point is, without positional arguments you can improve the ordering 
at any time. With positional arguments, you are stuck and have to get it 
right upfront.

David
Dec 28 2011
parent reply Don <nospam nospam.com> writes:
On 29.12.2011 04:48, David Nadlinger wrote:

 On 12/29/11 3:46 AM, Timon Gehr wrote:

 My point is, without named arguments you can improve the names at any
 time. With named arguments, you are stuck and have to get it right
 upfront.


 My point is, without positional arguments you can improve the ordering
 at any time. With positional arguments, you are stuck and have to get it
 right upfront.

 David


That's rubbish! Unless you plan to disallow positional arguments...
Dec 29 2011
next sibling parent Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
Naming is much less error-prone, then positioning, because change in
position is much less obvious (especially for parameters of the same
type).
When you write a class or a function you also need to come up with a
name, but you don't think of it as being forced to think ahead.
You'll always need to think ahead no matter what you do. A
sufficiently easy named parameter mechanism can easily allow you to
deprecate names if necessary.
Moreover, disallowing positional parameters is absolutely not
necessary, because it would lead to ugly code:

sin(5)
sin(x : 5)

I think the best idea would be to allow both named and positional, but
disallow mixing them. That is, you can either pass all your parameters
by name or by position.

int[2] makeAPoint(int x, int y) { return [x, y]; }

unittest
{
    auto a0 = makeAPoint(5, 7); // valid
    auto a1 = makeAPoint(x : 5, y : 7); // valid
    auto a2 = makeAPoint(5, y : 7); // invalid
    auto a2 = makeAPoint(x : 5, 7); // invalid
}

I really don't see any benefits in allowing mixed calls. in those
cases you might as well encapsulate the parameters in a structure.

On Thu, Dec 29, 2011 at 12:08 PM, Don <nospam nospam.com> wrote:

 On 29.12.2011 04:48, David Nadlinger wrote:

 On 12/29/11 3:46 AM, Timon Gehr wrote:

 My point is, without named arguments you can improve the names at any
 time. With named arguments, you are stuck and have to get it right
 upfront.



 My point is, without positional arguments you can improve the ordering
 at any time. With positional arguments, you are stuck and have to get it
 right upfront.

 David



 That's rubbish! Unless you plan to disallow positional arguments...




-- 
Bye,
Gor Gyolchanyan.
Dec 29 2011
prev sibling parent reply Derek <ddparnell bigpond.com> writes:
On Thu, 29 Dec 2011 19:08:36 +1100, Don <nospam nospam.com> wrote:


 On 29.12.2011 04:48, David Nadlinger wrote:

 On 12/29/11 3:46 AM, Timon Gehr wrote:

 My point is, without named arguments you can improve the names at any
 time. With named arguments, you are stuck and have to get it right
 upfront.


 My point is, without positional arguments you can improve the ordering
 at any time. With positional arguments, you are stuck and have to get it
 right upfront.

 David


 That's rubbish! Unless you plan to disallow positional arguments...


Maybe you missed the point?

I see the point in David's response as being that regardless of whether we  
have positional or named parameters, once exposed, they are pretty well  
set in concrete. I think that no one is suggesting that position  
parameters are to be replaced by named ones. The upshot of the idea would  
be that a API user would be free to choose between whatever *they* felt  
was appropriate.


-- 
Derek Parnell
Melbourne, Australia
Dec 29 2011
parent reply Don <nospam nospam.com> writes:
On 29.12.2011 09:39, Derek wrote:

 On Thu, 29 Dec 2011 19:08:36 +1100, Don <nospam nospam.com> wrote:


 On 29.12.2011 04:48, David Nadlinger wrote:

 On 12/29/11 3:46 AM, Timon Gehr wrote:

 My point is, without named arguments you can improve the names at any
 time. With named arguments, you are stuck and have to get it right
 upfront.


 My point is, without positional arguments you can improve the ordering
 at any time. With positional arguments, you are stuck and have to get it
 right upfront.

 David


 That's rubbish! Unless you plan to disallow positional arguments...


 Maybe you missed the point?

 I see the point in David's response as being that regardless of whether
 we have positional or named parameters, once exposed, they are pretty
 well set in concrete. I think that no one is suggesting that position
 parameters are to be replaced by named ones. The upshot of the idea
 would be that a API user would be free to choose between whatever *they*
 felt was appropriate.


I'm not aware of any languages where positional arguments are not 
supported. The restrictions imposed by named arguments are a pure 
superset of the restrictions imposed by positional arguments.

David's post implies that they are two independent approaches.

It's pretty obvious what happens when you have named arguments: if you 
make a poor choice in naming an argument, you generally shouldn't fix 
it. Documentation suffers.
Named arguments WILL reduce code quality in some cases.

There are definitely cases where named arguments are beneficial, though 
I suspect that most of them involve poorly designed functions. (The 
Windows CreateFont() function is my favourite example).

As an always-on feature, I can see as more downsides than upsides.
OTOH if it were an opt-in feature (for the library writer), I'd be 
completely in favour.
Dec 29 2011
parent reply so <so so.so> writes:
On Thu, 29 Dec 2011 11:48:13 +0200, Don <nospam nospam.com> wrote:


 I'm not aware of any languages where positional arguments are not  
 supported. The restrictions imposed by named arguments are a pure  
 superset of the restrictions imposed by positional arguments.


Don, it is a made up argument no one suggesting that.
Forget their implementations in other languages.
NP won't change a single thing for those that don't want to use it.

Rules must be simple. As a user you either use NP for the function  
entirely or don't use it, no mix.


 David's post implies that they are two independent approaches.

 It's pretty obvious what happens when you have named arguments: if you  
 make a poor choice in naming an argument, you generally shouldn't fix  
 it. Documentation suffers.
 Named arguments WILL reduce code quality in some cases.


When you change a parameter name, you change interfaces file and  
documentation.
Your user will recompile/reread regardless, because you came up with a new  
version.
Now with NP those that "want to bother" will edit their codes, he asked  
for it.

If you say someone will be forced to do that i have no argument against  
that, you are right.
Dec 29 2011
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday, December 29, 2011 18:49:51 so wrote:

 When you change a parameter name, you change interfaces file and
 documentation.
 Your user will recompile/reread regardless, because you came up with a new
 version.
 Now with NP those that "want to bother" will edit their codes, he asked
 for it.
 
 If you say someone will be forced to do that i have no argument against
 that, you are right.


Recompilation is one thing. Having to change your code is another. Sure, if a 
file gets changed, when you recompile, any code importing that module will have 
to be rebuilt, but it doesn't have to be changed. With named arguments, if a 
parameter change were made, youe'd have to go and change any code which used 
it as a named argument - just like if you rename a function, you have to 
change any code which calls that function even if that function does exactly 
the same thing that it did before.

Introducing named arguments makes a function's parameters part of the API and 
introduces yet another point where code breakage can occur due to code 
changes. And that is a _very_ negative aspect of named arguments IMHO.

- Jonathan M Davis
Dec 29 2011
parent reply so <so so.so> writes:
On Thu, 29 Dec 2011 23:59:46 +0200, Jonathan M Davis <jmdavisProg gmx.com>  
wrote:


 Introducing named arguments makes a function's parameters part of the  
 API and
 introduces yet another point where code breakage can occur due to code
 changes. And that is a _very_ negative aspect of named arguments IMHO.


Yes but luckily i think it is the only downside. You have to edit, if you  
(or your boss) asked for.
Now only question is if it worths. Remembering all those cryptic parameter  
passing cases i think it does.
And good thing is that it is an additive change to the language.
Dec 30 2011
parent Don <nospam nospam.com> writes:
On 31.12.2011 02:37, so wrote:

 On Thu, 29 Dec 2011 23:59:46 +0200, Jonathan M Davis
 <jmdavisProg gmx.com> wrote:


 Introducing named arguments makes a function's parameters part of the
 API and
 introduces yet another point where code breakage can occur due to code
 changes. And that is a _very_ negative aspect of named arguments IMHO.


 Yes but luckily i think it is the only downside. You have to edit, if
 you (or your boss) asked for.
 Now only question is if it worths. Remembering all those cryptic
 parameter passing cases i think it does.
 And good thing is that it is an additive change to the language.


But if you're a library writer, and you change a parameter name, users 
_will_ complain. In practice, this means you can't change them, even if 
it was a really bad name.

I also find it interesting that at the same time as we're making 
anonymous functions much easier to write, people want to remove the 
ability to have anonymous parameters.

It isn't an additive change to the language. It reinterprets existing code.
Dec 31 2011
prev sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 28 December 2011 at 20:58:33 UTC, Jonathan M Davis 
wrote:

 Since they affect the API, they _do_ hurt


In my web.d, I support named and positional parameters for
remote calls.

I almost always use the positional parameters exactly because
they are not affected by name changes in the server app.

It's just so much easier to handle changes when the names
don't matter.


Though it might not be so bad in D since static checks
can help. I remember one time this was discussed, it was
suggested to allow the name if and only if the position
is correct too.

void foo(int a, int b);
foo(a: 1, b: 0); // ok
foo(A: 1, b: 0); // wrong name
foo(b: 1, a: 0); // wrong names because position is swapped


Though imo if you want that, you could always just use a comment.
Dec 28 2011
prev sibling parent bearophile <bearophileHUGS lycos.com> writes:
Jonathan M Davis:


 The primary reason that I really don't like named arguments is the fact that
 the names of the parameters become part of the API.


Sometimes I don't mind to make the names part of the API.
And as you remember we have suggested an idea adapted from Scala.


void foo(int x) {}
void main() {
    foo(x: 5);
}


A deprecated() gives some transition time to change the API:

void foo(int xx deprecated(x)) {}
void main() {
    foo(x: 5); // deprecated 'x' warning
    foo(xx: 5);
}



 I also don't think that
 they add much unless you have functions with way too many parameters, and
 those sorts of functions shouldn't be happening anyway.


I'd like to use names even for functions with 3 arguments.
And named arguments offer you more flexibility in using functions. As example
look at Python built-in sorted (that performs a schwartz sort on a copy of the
input sequence), that has two optional arguments, using them with their name is
the idiomatic way in Python because you are able to use only one of them at a
time:



 a = [1, 5, -3, 9, -2]
 sorted(a)






[-3, -2, 1, 5, 9]

 sorted(a, key=abs)






[1, -2, -3, 5, 9]

 sorted(a, reverse=True)






[9, 5, 1, -2, -3]

-------------------------


 I'd hate to have a function like
 
 void func(float x, float y);
 
 where calling it
 
 func(1.0, 2.0);
 
 and
 
 func(y : 1.0, x : 2.0);
 
 don't do the same thing. All of a sudden, I have to pay attention to what
 names the arguments were given. I can't just read the function call like I
 would now. It becomes error-prone in that regard and violates the current
 expectations of argument order. It will make code harder to read for minimal
 benefit IMHO. I do _not_ think that name arguments are an improvement.


Expectations change and adapt to the language and you will read the function
calls in a different way, taking a look at the argument order too. In many
cases names are not present at the call point, so you don't need to take care
of this. If the names are present at the call point you take a look at the
order. The name of the arguments keep the code readable.

Regarding the "error-prone" nature of named arguments, I think you are wrong,
in Ada named arguments are regarded as means to reduce possible bugs, because
they avoid you to assign arguments "blindly" as now. In Python I like to know
what argument I am assigning an argument to, this avoids some mistakes at the
call point.

  

 If the
 example above were possible, then someone would use it in their code (even if
 I didn't), and I'd have to deal with all of the code readibility issues that
 it causes. Named arguments _would_ hurt the language even if they were purely
 optional.


Right, if language features like this are present they can't be really
"optional", you find them in code written by other people.

But named argument make code _more_ readable, because they tell you what
arguments you are assigning to.

Bye,
bearophile
Dec 28 2011
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-12-27 15:27, Alex Rønne Petersen wrote:

 On 27-12-2011 15:19, Alex Rønne Petersen wrote:

 On 27-12-2011 05:25, Andrei Alexandrescu wrote:

 https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc




 Andrei


 Awesome!

 Now the only gripe I have left is type inference for lambdas passed as
 regular function parameters. Is this something we will see anytime soon?

 - Alex


 Just to make it clear what I want to be able to do (simple example with
 arrays):

 T[] filter(T)(T[] items, scope bool delegate(T) predicate)
 {
 T[] newItems;

 foreach (item; items)
 if (predicate(item))
 newItems ~= item;

 return newItems;
 }

 auto ints = filter([0, 1, 2, 3, 4, 5], x => x % 2 != 0);

 Or perhaps even better, when we get fully working UFCS:

 auto ints = [0, 1, 2, 3, 4, 5].filter(x => x % 2 != 0);

 DMD should be able to infer the parameter type(s) of the delegate I'm
 passing, since that's clear from the array being passed. (I would

 sophisticated for an imperative language.)

 - Alex


The type inference in Scala is very powerful as well.

-- 
/Jacob Carlborg
Dec 28 2011
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/27/11 8:19 AM, Alex Rønne Petersen wrote:

 Now the only gripe I have left is type inference for lambdas passed as
 regular function parameters. Is this something we will see anytime soon?


It's among the [tdpl] bugs, so I hope fairly soon.

Andrei
Dec 27 2011
prev sibling next sibling parent reply Joshua Reusch <yoschi arkandos.de> writes:
Am 27.12.2011 05:25, schrieb Andrei Alexandrescu:

 https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc


 Andrei


-------------
import std.algorithm;

void main() {
	auto arr = [0, 5, 4, 3, 2, 1];
	sort!((a, b) => a < b)(arr);
}
-------------
$ ./dmd lambda_test
dmd: malloc.c:3096: sYSMALLOc: Assertion `(old_top == (((mbinptr) 
(((char *) &((av)->bins[((1) - 1) * 2])) - __builtin_offsetof (struct 
malloc_chunk, fd)))) && old_size == 0) || ((unsigned long) (old_size) >= 
(unsigned long)((((__builtin_offsetof (struct malloc_chunk, 
fd_nextsize))+((2 * (sizeof(size_t))) - 1)) & ~((2 * (sizeof(size_t))) - 
1))) && ((old_top)->size & 0x1) && ((unsigned long)old_end & pagemask) 
== 0)' failed.
$


This also "works" with other functions from std.algorithm.
Dec 27 2011
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/27/11 9:21 AM, Joshua Reusch wrote:

 Am 27.12.2011 05:25, schrieb Andrei Alexandrescu:

 https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc



 Andrei


 -------------
 import std.algorithm;

 void main() {
 auto arr = [0, 5, 4, 3, 2, 1];
 sort!((a, b) => a < b)(arr);
 }
 -------------
 $ ./dmd lambda_test
 dmd: malloc.c:3096: sYSMALLOc: Assertion `(old_top == (((mbinptr)
 (((char *) &((av)->bins[((1) - 1) * 2])) - __builtin_offsetof (struct
 malloc_chunk, fd)))) && old_size == 0) || ((unsigned long) (old_size) >=
 (unsigned long)((((__builtin_offsetof (struct malloc_chunk,
 fd_nextsize))+((2 * (sizeof(size_t))) - 1)) & ~((2 * (sizeof(size_t))) -
 1))) && ((old_top)->size & 0x1) && ((unsigned long)old_end & pagemask)
 == 0)' failed.
 $


 This also "works" with other functions from std.algorithm.


Not even 11h before the first bug report. What's odd about this is that 
the code works with both the string syntax and the "long lambda" syntax, 
and the new syntax is simply doing a rewrite to the long lambda syntax.

Andrei
Dec 27 2011
prev sibling parent reply Torarin <torarind gmail.com> writes:
2011/12/27 Joshua Reusch <yoschi arkandos.de>:

 Am 27.12.2011 05:25, schrieb Andrei Alexandrescu:

 https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155=




a85abf986eae99c37c0dc

 Andrei



 -------------
 import std.algorithm;

 void main() {
 =A0 =A0 =A0 =A0auto arr =3D [0, 5, 4, 3, 2, 1];
 =A0 =A0 =A0 =A0sort!((a, b) =3D> a < b)(arr);
 }
 -------------
 $ ./dmd lambda_test
 dmd: malloc.c:3096: sYSMALLOc: Assertion `(old_top =3D=3D (((mbinptr) (((=


char *)

 &((av)->bins[((1) - 1) * 2])) - __builtin_offsetof (struct malloc_chunk,
 fd)))) && old_size =3D=3D 0) || ((unsigned long) (old_size) >=3D (unsigne=


d

 long)((((__builtin_offsetof (struct malloc_chunk, fd_nextsize))+((2 *
 (sizeof(size_t))) - 1)) & ~((2 * (sizeof(size_t))) - 1))) &&
 ((old_top)->size & 0x1) && ((unsigned long)old_end & pagemask) =3D=3D 0)'
 failed.
 $


 This also "works" with other functions from std.algorithm.


Did you do a clean before compiling? I forgot, and got the same error.

Torarin
Dec 27 2011
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/27/11 9:51 AM, Torarin wrote:

 2011/12/27 Joshua Reusch<yoschi arkandos.de>:

 Am 27.12.2011 05:25, schrieb Andrei Alexandrescu:

 https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc


 Andrei



 -------------
 import std.algorithm;

 void main() {
         auto arr = [0, 5, 4, 3, 2, 1];
         sort!((a, b) =>  a<  b)(arr);
 }
 -------------
 $ ./dmd lambda_test
 dmd: malloc.c:3096: sYSMALLOc: Assertion `(old_top == (((mbinptr) (((char *)
 &((av)->bins[((1) - 1) * 2])) - __builtin_offsetof (struct malloc_chunk,
 fd))))&&  old_size == 0) || ((unsigned long) (old_size)>= (unsigned
 long)((((__builtin_offsetof (struct malloc_chunk, fd_nextsize))+((2 *
 (sizeof(size_t))) - 1))&  ~((2 * (sizeof(size_t))) - 1)))&&
 ((old_top)->size&  0x1)&&  ((unsigned long)old_end&  pagemask) == 0)'
 failed.
 $


 This also "works" with other functions from std.algorithm.


 Did you do a clean before compiling? I forgot, and got the same error.

 Torarin


I confirm the new syntax works after a rebase and clean rebuild.

Andrei
Dec 27 2011
parent reply "Trass3r" <un known.com> writes:
On Tuesday, 27 December 2011 at 16:33:30 UTC, Andrei Alexandrescu 
wrote:

 On 12/27/11 9:51 AM, Torarin wrote:

 2011/12/27 Joshua Reusch<yoschi arkandos.de>:

 $ ./dmd lambda_test
 dmd: malloc.c:3096: sYSMALLOc: Assertion `(old_top == 
 (((mbinptr) (((char *)
 &((av)->bins[((1) - 1) * 2])) - __builtin_offsetof (struct 
 malloc_chunk,
 fd))))&&  old_size == 0) || ((unsigned long) (old_size)>= 
 (unsigned
 long)((((__builtin_offsetof (struct malloc_chunk, 
 fd_nextsize))+((2 *
 (sizeof(size_t))) - 1))&  ~((2 * (sizeof(size_t))) - 1)))&&
 ((old_top)->size&  0x1)&&  ((unsigned long)old_end&  
 pagemask) == 0)'
 failed.


 Did you do a clean before compiling? I forgot, and got the 
 same error.


 I confirm the new syntax works after a rebase and clean rebuild.


I've always wondered how dmd manages to do that.
It's well known that dmd gives you a nut kick if you try to 
compile D code incrementally.
But even the dmd source itself has to be rebuilt every time if 
you don't want strange errors and that's C++.

I don't even know if it's a laughing matter or not.
Dec 27 2011
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/27/11 10:50 AM, Trass3r wrote:

 On Tuesday, 27 December 2011 at 16:33:30 UTC, Andrei Alexandrescu wrote:

 On 12/27/11 9:51 AM, Torarin wrote:

 2011/12/27 Joshua Reusch<yoschi arkandos.de>:

 $ ./dmd lambda_test
 dmd: malloc.c:3096: sYSMALLOc: Assertion `(old_top == (((mbinptr)
 (((char *)
 &((av)->bins[((1) - 1) * 2])) - __builtin_offsetof (struct
 malloc_chunk,
 fd))))&& old_size == 0) || ((unsigned long) (old_size)>= (unsigned
 long)((((__builtin_offsetof (struct malloc_chunk, fd_nextsize))+((2 *
 (sizeof(size_t))) - 1))& ~((2 * (sizeof(size_t))) - 1)))&&
 ((old_top)->size& 0x1)&& ((unsigned long)old_end& pagemask) == 0)'
 failed.


 Did you do a clean before compiling? I forgot, and got the same error.


 I confirm the new syntax works after a rebase and clean rebuild.


 I've always wondered how dmd manages to do that.
 It's well known that dmd gives you a nut kick if you try to compile D
 code incrementally.
 But even the dmd source itself has to be rebuilt every time if you don't
 want strange errors and that's C++.

 I don't even know if it's a laughing matter or not.


I think it's a makefile matter.

Andrei
Dec 27 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/27/2011 9:40 AM, Andrei Alexandrescu wrote:

 On 12/27/11 10:50 AM, Trass3r wrote:

 But even the dmd source itself has to be rebuilt every time if you don't
 want strange errors and that's C++.

 I don't even know if it's a laughing matter or not.


 I think it's a makefile matter.


The makefile for dmd doesn't have the dependencies on .h files set up properly. 
If a .h file is changed, the thing to do is make clean and then build.

(Even when I do set up the .h file dependencies right, bit rot creeps in and 
wastes my time trying to figure out what went wrong. I just make clean and
rebuild.)
Dec 27 2011
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/27/11 12:03 PM, Walter Bright wrote:

 On 12/27/2011 9:40 AM, Andrei Alexandrescu wrote:

 On 12/27/11 10:50 AM, Trass3r wrote:

 But even the dmd source itself has to be rebuilt every time if you don't
 want strange errors and that's C++.

 I don't even know if it's a laughing matter or not.


 I think it's a makefile matter.


 The makefile for dmd doesn't have the dependencies on .h files set up
 properly. If a .h file is changed, the thing to do is make clean and
 then build.

 (Even when I do set up the .h file dependencies right, bit rot creeps in
 and wastes my time trying to figure out what went wrong. I just make
 clean and rebuild.)


Problem is lack of automation (in this case makdepend). As usual, I have 
an optimistic view on the help that automation can bring to our project.

Andrei
Dec 27 2011
next sibling parent Joshua Reusch <yoschi arkandos.de> writes:
Am 27.12.2011 19:09, schrieb Andrei Alexandrescu:

 On 12/27/11 12:03 PM, Walter Bright wrote:

 On 12/27/2011 9:40 AM, Andrei Alexandrescu wrote:

 On 12/27/11 10:50 AM, Trass3r wrote:

 But even the dmd source itself has to be rebuilt every time if you
 don't
 want strange errors and that's C++.

 I don't even know if it's a laughing matter or not.


 I think it's a makefile matter.


 The makefile for dmd doesn't have the dependencies on .h files set up
 properly. If a .h file is changed, the thing to do is make clean and
 then build.

 (Even when I do set up the .h file dependencies right, bit rot creeps in
 and wastes my time trying to figure out what went wrong. I just make
 clean and rebuild.)


 Problem is lack of automation (in this case makdepend). As usual, I have
 an optimistic view on the help that automation can bring to our project.

 Andrei


ok, after a clean/rebuild it works. my fault, sorry ...
Dec 27 2011
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/27/2011 10:09 AM, Andrei Alexandrescu wrote:

 Problem is lack of automation (in this case makdepend).


I've used makedepend before. (I even wrote one!) It just never caught on.


 As usual, I have an
 optimistic view on the help that automation can bring to our project.


All my build scripts start with make clean. Having make clean work right is 
something I do make an effort towards.
Dec 27 2011
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/27/11 2:10 PM, Walter Bright wrote:

 On 12/27/2011 10:09 AM, Andrei Alexandrescu wrote:

 Problem is lack of automation (in this case makdepend).


 I've used makedepend before. (I even wrote one!) It just never caught on.


It's improved a tone lately, particularly since gcc has built-in support 
for it. It all comes back to using Unix as your development environment.


  > As usual, I have an
  > optimistic view on the help that automation can bring to our project.

 All my build scripts start with make clean.


One good realization to make is how less efficient that makes you. You 
got used to that overhead so plentily, you consider it now par for the 
course.


Andrei
Dec 27 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/27/2011 12:28 PM, Andrei Alexandrescu wrote:

 One good realization to make is how less efficient that makes you. You got used
 to that overhead so plentily, you consider it now par for the course.


What takes time is running the unittests, not compiling dmd.
Dec 27 2011
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/27/11 2:38 PM, Walter Bright wrote:

 On 12/27/2011 12:28 PM, Andrei Alexandrescu wrote:

 One good realization to make is how less efficient that makes you. You
 got used
 to that overhead so plentily, you consider it now par for the course.


 What takes time is running the unittests, not compiling dmd.


Then _that_ is what you consider par for the course! :o)

Andrei
Dec 27 2011
parent reply Peter Alexander <peter.alexander.au gmail.com> writes:
On 27/12/11 8:40 PM, Andrei Alexandrescu wrote:

 On 12/27/11 2:38 PM, Walter Bright wrote:

 On 12/27/2011 12:28 PM, Andrei Alexandrescu wrote:

 One good realization to make is how less efficient that makes you. You
 got used
 to that overhead so plentily, you consider it now par for the course.


 What takes time is running the unittests, not compiling dmd.


 Then _that_ is what you consider par for the course! :o)

 Andrei


Has anyone looked into what causes the unittests to take so long? I find 
it hard to believe that they need to take as long as they do.
Dec 28 2011
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 12/28/2011 10:53 AM, Peter Alexander wrote:

 On 27/12/11 8:40 PM, Andrei Alexandrescu wrote:

 On 12/27/11 2:38 PM, Walter Bright wrote:

 On 12/27/2011 12:28 PM, Andrei Alexandrescu wrote:

 One good realization to make is how less efficient that makes you. You
 got used
 to that overhead so plentily, you consider it now par for the course.


 What takes time is running the unittests, not compiling dmd.


 Then _that_ is what you consider par for the course! :o)

 Andrei


 Has anyone looked into what causes the unittests to take so long? I find
 it hard to believe that they need to take as long as they do.


They have to be run for many different combinations of compiler flags iirc.
Dec 28 2011
parent reply Don <nospam nospam.com> writes:
On 28.12.2011 13:14, Timon Gehr wrote:

 On 12/28/2011 10:53 AM, Peter Alexander wrote:

 On 27/12/11 8:40 PM, Andrei Alexandrescu wrote:

 On 12/27/11 2:38 PM, Walter Bright wrote:

 On 12/27/2011 12:28 PM, Andrei Alexandrescu wrote:

 One good realization to make is how less efficient that makes you. You
 got used
 to that overhead so plentily, you consider it now par for the course.


 What takes time is running the unittests, not compiling dmd.


 Then _that_ is what you consider par for the course! :o)

 Andrei


 Has anyone looked into what causes the unittests to take so long? I find
 it hard to believe that they need to take as long as they do.


 They have to be run for many different combinations of compiler flags iirc.


AFAIK there has never been a failure which wasn't with one of:
(no flags)
-O -release -inline
-g -O -release -inline

But why do the Phobos unit tests take so long? They used to take a 
matter of seconds, now they take forever.

On D1, they still take only about 10 seconds. On D2 they are now longer 
than the compiler tests with the minimal flag options.
Dec 29 2011
parent reply "Marco Leise" <Marco.Leise gmx.de> writes:
Am 29.12.2011, 09:16 Uhr, schrieb Don <nospam nospam.com>:


 On 28.12.2011 13:14, Timon Gehr wrote:

 On 12/28/2011 10:53 AM, Peter Alexander wrote:

 On 27/12/11 8:40 PM, Andrei Alexandrescu wrote:

 On 12/27/11 2:38 PM, Walter Bright wrote:

 On 12/27/2011 12:28 PM, Andrei Alexandrescu wrote:

 One good realization to make is how less efficient that makes you.  
 You
 got used
 to that overhead so plentily, you consider it now par for the  
 course.


 What takes time is running the unittests, not compiling dmd.


 Then _that_ is what you consider par for the course! :o)

 Andrei


 Has anyone looked into what causes the unittests to take so long? I  
 find
 it hard to believe that they need to take as long as they do.


 They have to be run for many different combinations of compiler flags  
 iirc.


 AFAIK there has never been a failure which wasn't with one of:
 (no flags)
 -O -release -inline
 -g -O -release -inline

 But why do the Phobos unit tests take so long? They used to take a  
 matter of seconds, now they take forever.

 On D1, they still take only about 10 seconds. On D2 they are now longer  
 than the compiler tests with the minimal flag options.


2.055 hat problems with -O -release -inline -noboundscheck (three of those  
anyway, including noboundscheck)
Dec 31 2011
parent Don <nospam nospam.com> writes:
On 31.12.2011 15:55, Marco Leise wrote:

 Am 29.12.2011, 09:16 Uhr, schrieb Don <nospam nospam.com>:


 On 28.12.2011 13:14, Timon Gehr wrote:

 On 12/28/2011 10:53 AM, Peter Alexander wrote:

 On 27/12/11 8:40 PM, Andrei Alexandrescu wrote:

 On 12/27/11 2:38 PM, Walter Bright wrote:

 On 12/27/2011 12:28 PM, Andrei Alexandrescu wrote:

 One good realization to make is how less efficient that makes
 you. You
 got used
 to that overhead so plentily, you consider it now par for the
 course.


 What takes time is running the unittests, not compiling dmd.


 Then _that_ is what you consider par for the course! :o)

 Andrei


 Has anyone looked into what causes the unittests to take so long? I
 find
 it hard to believe that they need to take as long as they do.


 They have to be run for many different combinations of compiler flags
 iirc.


 AFAIK there has never been a failure which wasn't with one of:
 (no flags)
 -O -release -inline
 -g -O -release -inline

 But why do the Phobos unit tests take so long? They used to take a
 matter of seconds, now they take forever.

 On D1, they still take only about 10 seconds. On D2 they are now
 longer than the compiler tests with the minimal flag options.


 2.055 hat problems with -O -release -inline -noboundscheck (three of
 those anyway, including noboundscheck)


Ah, yes. -release used to include -noboundscheck. Thanks.
The list should be
(no flags)
-O -release -inline -noboundscheck
-g -O -release -inline -noboundscheck
Jan 01 2012
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2011-12-27 05:25, Andrei Alexandrescu wrote:

 https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc


 Andrei


Now that's very cool. Does it work for non-template arguments as well.

-- 
/Jacob Carlborg
Dec 27 2011
parent reply =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 27-12-2011 21:32, Jacob Carlborg wrote:

 On 2011-12-27 05:25, Andrei Alexandrescu wrote:

 https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc



 Andrei


 Now that's very cool. Does it work for non-template arguments as well.


Nope. When passing such lambdas as regular arguments, there's no inference.

- Alex
Dec 27 2011
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 12/27/2011 10:53 PM, Alex Rønne Petersen wrote:

 On 27-12-2011 21:32, Jacob Carlborg wrote:

 On 2011-12-27 05:25, Andrei Alexandrescu wrote:

 https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc




 Andrei


 Now that's very cool. Does it work for non-template arguments as well.


 Nope. When passing such lambdas as regular arguments, there's no inference.

 - Alex


... yet.

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

Anyway, his question seemed to be about whether or not the '=>' syntax 
can be used for ordinary delegate literals, which it can: (int x) => x
Dec 27 2011
next sibling parent =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 27-12-2011 23:18, Timon Gehr wrote:

 On 12/27/2011 10:53 PM, Alex Rønne Petersen wrote:

 On 27-12-2011 21:32, Jacob Carlborg wrote:

 On 2011-12-27 05:25, Andrei Alexandrescu wrote:

 https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc





 Andrei


 Now that's very cool. Does it work for non-template arguments as well.


 Nope. When passing such lambdas as regular arguments, there's no
 inference.

 - Alex


 ... yet.

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

 Anyway, his question seemed to be about whether or not the '=>' syntax
 can be used for ordinary delegate literals, which it can: (int x) => x


That bug needs very high priority.

- Alex
Dec 27 2011
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-12-27 23:18, Timon Gehr wrote:

 On 12/27/2011 10:53 PM, Alex Rønne Petersen wrote:

 On 27-12-2011 21:32, Jacob Carlborg wrote:

 On 2011-12-27 05:25, Andrei Alexandrescu wrote:

 https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc





 Andrei


 Now that's very cool. Does it work for non-template arguments as well.


 Nope. When passing such lambdas as regular arguments, there's no
 inference.

 - Alex


 ... yet.

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

 Anyway, his question seemed to be about whether or not the '=>' syntax
 can be used for ordinary delegate literals, which it can: (int x) => x


Yes, exactly. Thanks.

-- 
/Jacob Carlborg
Dec 28 2011
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-12-27 22:53, Alex Rønne Petersen wrote:

 On 27-12-2011 21:32, Jacob Carlborg wrote:

 On 2011-12-27 05:25, Andrei Alexandrescu wrote:

 https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc




 Andrei


 Now that's very cool. Does it work for non-template arguments as well.


 Nope. When passing such lambdas as regular arguments, there's no inference.

 - Alex


Yeah, but does the new syntax work:

void foo (int delegate (int) dg);

foo((int a) => 3);

-- 
/Jacob Carlborg
Dec 28 2011
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 12/27/2011 05:25 AM, Andrei Alexandrescu wrote:

 https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc


 Andrei


Great! =)

What about making => syntax available to named functions as well?

class C{
     private int x;
     int getX() => x;
}


void main(){
     int[] arr;
     bool isOdd(int x) => x&1;
     writeln(arr.filter!isOdd());
}
Dec 27 2011
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 12/27/2011 11:27 PM, Timon Gehr wrote:

 On 12/27/2011 05:25 AM, Andrei Alexandrescu wrote:

 https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc



 Andrei


 Great! =)

 What about making => syntax available to named functions as well?

 class C{
 private int x;
 int getX() => x;
 }


 void main(){
 int[] arr;
 bool isOdd(int x) => x&1;
 writeln(arr.filter!isOdd());
 }


Also,

=> expr

should imo be a shorthand for

() => expr.

It saves some ((())(()))().
Dec 27 2011
parent reply bearophile <bearophileHUGS lycos.com> writes:
Timon Gehr: 


 => expr
 
 should imo be a shorthand for
 
 () => expr.
 
 It saves some ((())(()))().


It saves few (), but zero argument lambdas aren't that common in my
functional-style code, and I think it decreases syntax uniformity and code
readability. So I think it's a bad idea.

On the other hand I think extending the applicability of this syntax to free
functions/methods (as in Scala and Ada2012) is a nice idea, to shorten tiny
functions/methods, that are common enough:

class C {
     private int x;
     int getX() => x;
}

------------------------

Walter:


They expect to see it, or else they mark D as "not having lambdas" and "not
supporting functional programming".<


To me this sounds like a bit silly argument to base language design on.

In my opinion the most important reason for the introduction of this anonymous
function syntax is that it makes D functional-style code (and generally code
that uses lot of callbacks) less noisy, so it makes it more easy to write and
read.

Bye,
bearophile
Dec 28 2011
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2011-12-28 13:54, bearophile wrote:

 Timon Gehr:


 =>  expr

 should imo be a shorthand for

 () =>  expr.

 It saves some ((())(()))().


 It saves few (), but zero argument lambdas aren't that common in my
functional-style code, and I think it decreases syntax uniformity and code
readability. So I think it's a bad idea.


It can already be done with the lazy arguments.

void foo (lazy int a)
{
     auto b = a();
}

int bar ();
foo(bar());

-- 
/Jacob Carlborg
Dec 28 2011
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 12/28/2011 05:59 PM, Jacob Carlborg wrote:

 On 2011-12-28 13:54, bearophile wrote:

 Timon Gehr:


 => expr

 should imo be a shorthand for

 () => expr.

 It saves some ((())(()))().


 It saves few (), but zero argument lambdas aren't that common in my
 functional-style code, and I think it decreases syntax uniformity and
 code readability. So I think it's a bad idea.


 It can already be done with the lazy arguments.

 void foo (lazy int a)
 {
 auto b = a();
 }

 int bar ();
 foo(bar());


It is not the same thing. lazy arguments do not create a closure.
Dec 28 2011
parent Jacob Carlborg <doob me.com> writes:
On 2011-12-28 18:54, Timon Gehr wrote:

 On 12/28/2011 05:59 PM, Jacob Carlborg wrote:

 On 2011-12-28 13:54, bearophile wrote:

 Timon Gehr:


 => expr

 should imo be a shorthand for

 () => expr.

 It saves some ((())(()))().


 It saves few (), but zero argument lambdas aren't that common in my
 functional-style code, and I think it decreases syntax uniformity and
 code readability. So I think it's a bad idea.


 It can already be done with the lazy arguments.

 void foo (lazy int a)
 {
 auto b = a();
 }

 int bar ();
 foo(bar());


 It is not the same thing. lazy arguments do not create a closure.


Didn't thought of that.

-- 
/Jacob Carlborg
Dec 28 2011
prev sibling parent reply deadalnix <deadalnix gmail.com> writes:
Le 28/12/2011 13:54, bearophile a écrit :

 Timon Gehr:


 =>  expr

 should imo be a shorthand for

 () =>  expr.

 It saves some ((())(()))().


 It saves few (), but zero argument lambdas aren't that common in my
functional-style code, and I think it decreases syntax uniformity and code
readability. So I think it's a bad idea.

 On the other hand I think extending the applicability of this syntax to free
functions/methods (as in Scala and Ada2012) is a nice idea, to shorten tiny
functions/methods, that are common enough:

 class C {
       private int x;
       int getX() =>  x;
 }


That would be great ! Uniformity is something we should look for.


 ------------------------

 Walter:


 They expect to see it, or else they mark D as "not having lambdas" and "not
supporting functional programming".<


 To me this sounds like a bit silly argument to base language design on.

 In my opinion the most important reason for the introduction of this anonymous
function syntax is that it makes D functional-style code (and generally code
that uses lot of callbacks) less noisy, so it makes it more easy to write and
read.

 Bye,
 bearophile


Both argument are fallacy. Javascript is a successful language (even if 
some design decisions are arguably very bad). It use a lot of callback, 
and promote event drivent programming so this type of consrtruct is used 
everywhere. In addition, in Javascript, code source size matters.

The syntax to do such a thing is more verbose in javascript. So 
definitively, this is a nice syntax, but this isn't that ground 
breaking, and this isn't even required for people to use this type of 
constructs.
Dec 28 2011
next sibling parent Max Samukha <maxsamukha gmail.com> writes:
On 12/28/2011 07:15 PM, deadalnix wrote:


 The syntax to do such a thing is more verbose in javascript. So
 definitively, this is a nice syntax, but this isn't that ground
 breaking, and this isn't even required for people to use this type of
 constructs.


People keep complaining about the verbosity of function syntax in 
JavaScript. There has been several attempts to fix that. One prominent 
example is CoffeeScript.
Dec 28 2011
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-12-28 18:15, deadalnix wrote:

 Le 28/12/2011 13:54, bearophile a écrit :

 Timon Gehr:


 => expr

 should imo be a shorthand for

 () => expr.

 It saves some ((())(()))().


 It saves few (), but zero argument lambdas aren't that common in my
 functional-style code, and I think it decreases syntax uniformity and
 code readability. So I think it's a bad idea.

 On the other hand I think extending the applicability of this syntax
 to free functions/methods (as in Scala and Ada2012) is a nice idea, to
 shorten tiny functions/methods, that are common enough:

 class C {
 private int x;
 int getX() => x;
 }


 That would be great ! Uniformity is something we should look for.


 ------------------------

 Walter:


 They expect to see it, or else they mark D as "not having lambdas"
 and "not supporting functional programming".<


 To me this sounds like a bit silly argument to base language design on.

 In my opinion the most important reason for the introduction of this
 anonymous function syntax is that it makes D functional-style code
 (and generally code that uses lot of callbacks) less noisy, so it
 makes it more easy to write and read.

 Bye,
 bearophile


 Both argument are fallacy. Javascript is a successful language (even if
 some design decisions are arguably very bad). It use a lot of callback,
 and promote event drivent programming so this type of consrtruct is used
 everywhere. In addition, in Javascript, code source size matters.

 The syntax to do such a thing is more verbose in javascript. So
 definitively, this is a nice syntax, but this isn't that ground
 breaking, and this isn't even required for people to use this type of
 constructs.


I use CoffeeScript (which compiles to JavaScript) and it has a lot nice 
lambda syntax.

foo = (arg) ->
     arg()

foo ->


-- 
/Jacob Carlborg
Dec 28 2011
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-12-28 18:15, deadalnix wrote:

 Le 28/12/2011 13:54, bearophile a écrit :

 Timon Gehr:


 => expr

 should imo be a shorthand for

 () => expr.

 It saves some ((())(()))().


 It saves few (), but zero argument lambdas aren't that common in my
 functional-style code, and I think it decreases syntax uniformity and
 code readability. So I think it's a bad idea.

 On the other hand I think extending the applicability of this syntax
 to free functions/methods (as in Scala and Ada2012) is a nice idea, to
 shorten tiny functions/methods, that are common enough:

 class C {
 private int x;
 int getX() => x;
 }


 That would be great ! Uniformity is something we should look for.


 ------------------------

 Walter:


 They expect to see it, or else they mark D as "not having lambdas"
 and "not supporting functional programming".<


 To me this sounds like a bit silly argument to base language design on.

 In my opinion the most important reason for the introduction of this
 anonymous function syntax is that it makes D functional-style code
 (and generally code that uses lot of callbacks) less noisy, so it
 makes it more easy to write and read.

 Bye,
 bearophile


 Both argument are fallacy. Javascript is a successful language (even if
 some design decisions are arguably very bad). It use a lot of callback,
 and promote event drivent programming so this type of consrtruct is used
 everywhere. In addition, in Javascript, code source size matters.

 The syntax to do such a thing is more verbose in javascript. So
 definitively, this is a nice syntax, but this isn't that ground
 breaking, and this isn't even required for people to use this type of
 constructs.


I use CoffeeScript (which compiles to JavaScript) and it has a lot nicer 
lambda syntax.

foo = (arg) ->
     arg()

foo ->


-- 
/Jacob Carlborg
Dec 28 2011
prev sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
deadalnix:


 bearophile:

 In my opinion the most important reason for the introduction of
 this anonymous function syntax is that it makes D functional-style
 code (and generally code that uses lot of callbacks) less noisy,
 so it makes it more easy to write and read.





 Both argument are fallacy. Javascript is a successful language (even if
 some design decisions are arguably very bad). It use a lot of callback,
 and promote event drivent programming so this type of consrtruct is used
 everywhere. In addition, in Javascript, code source size matters.
 
 The syntax to do such a thing is more verbose in javascript. So
 definitively, this is a nice syntax, but this isn't that ground
 breaking, and this isn't even required for people to use this type of
 constructs.


Javascript is successful mostly for being the only language available on a very
important platform, not for its many qualities and features. D lacks a killer
app still, and it exists in an already mature ecosytem dominated by other
languages like C++. So it has to compete on different grounds of quality.

I agree the new short lambda syntax is not necessary, but it's good to have. I
have written a good amount of functional-style code in D2 (while I have not
written a significant amount of functional-style code in Javascript), I have
written some code in OCaML and Haskell, and I have seen that the amount of
parentheses and brackets in such D code make it not easy to write and read for
me, compared to equivalent code in more functional languages. So you need to
try harder if you want to change my mind :-)

Bye,
bearophile
Dec 28 2011
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 28 December 2011 at 22:57:29 UTC, bearophile wrote:

 (while I have not written a significant amount of 
 functional-style code in Javascript)


It looks fine if you use named functions or a little whitespace
around the literals (same as D!).
Dec 28 2011
parent reply Max Samukha <maxsamukha gmail.com> writes:
On 12/29/2011 01:49 AM, Adam D. Ruppe wrote:

 On Wednesday, 28 December 2011 at 22:57:29 UTC, bearophile wrote:

 (while I have not written a significant amount of functional-style
 code in Javascript)


 It looks fine if you use named functions or a little whitespace
 around the literals (same as D!).


I had been a stupidly staunch defender of braces/semicolons before I 
actually tried the languages with significant indentation. Since then, I 
find C-like syntaxes not so attractive, to say the least. It takes a 
while to fall out of the bad habit typing all that punctuation but the 
result is rewarding.

Comparing CoffeeScript and the equivalent JavaScript code at 
http://jashkenas.github.com/coffee-script/, it is obvious that 
JavaScript is unnecessarily noisy.
Dec 29 2011
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-12-29 10:07, Max Samukha wrote:

 On 12/29/2011 01:49 AM, Adam D. Ruppe wrote:

 On Wednesday, 28 December 2011 at 22:57:29 UTC, bearophile wrote:

 (while I have not written a significant amount of functional-style
 code in Javascript)


 It looks fine if you use named functions or a little whitespace
 around the literals (same as D!).


 I had been a stupidly staunch defender of braces/semicolons before I
 actually tried the languages with significant indentation. Since then, I
 find C-like syntaxes not so attractive, to say the least. It takes a
 while to fall out of the bad habit typing all that punctuation but the
 result is rewarding.

 Comparing CoffeeScript and the equivalent JavaScript code at
 http://jashkenas.github.com/coffee-script/, it is obvious that
 JavaScript is unnecessarily noisy.


I completely agree. CoffeeScript is a really nice language. Except for 
the nicer syntax it's also really nice to have proper class based object 
model (or at least as proper it can be since it's compiled to a 
prototype model).

-- 
/Jacob Carlborg
Dec 29 2011
prev sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Thursday, 29 December 2011 at 09:07:21 UTC, Max Samukha wrote:

 it is obvious that JavaScript is unnecessarily noisy.


Meh, one man's music is another man's noise.
Dec 29 2011
prev sibling next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Timon Gehr:


 What about making => syntax available to named functions as well?
 
 class C{
      private int x;
      int getX() => x;
 }
 
 
 void main(){
      int[] arr;
      bool isOdd(int x) => x&1;
      writeln(arr.filter!isOdd());
 }


From the Ada 2012 changes:
http://www.disca.upv.es/jorge/ae2010/slides/05-3_Language_Tech_Schonberg_Towards_Ada_2012.pdf


 To simplify the writing of pre/postconditions and predicates, allow
parametrized expressions (aka function bodies in package specs):


function Cube (X : integer) is (X ** 3);

Bye,
bearophile
Dec 27 2011
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2011-12-27 23:27, Timon Gehr wrote:

 On 12/27/2011 05:25 AM, Andrei Alexandrescu wrote:

 https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc



 Andrei


 Great! =)

 What about making => syntax available to named functions as well?

 class C{
 private int x;
 int getX() => x;
 }


 void main(){
 int[] arr;
 bool isOdd(int x) => x&1;
 writeln(arr.filter!isOdd());
 }


I wouldn't say no to that.

-- 
/Jacob Carlborg
Dec 28 2011
parent reply Don <nospam nospam.com> writes:
On 28.12.2011 17:41, Jacob Carlborg wrote:

 On 2011-12-27 23:27, Timon Gehr wrote:

 On 12/27/2011 05:25 AM, Andrei Alexandrescu wrote:

 https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc




 Andrei


 Great! =)

 What about making => syntax available to named functions as well?

 class C{
 private int x;
 int getX() => x;
 }


 void main(){
 int[] arr;
 bool isOdd(int x) => x&1;
 writeln(arr.filter!isOdd());
 }


 I wouldn't say no to that.


I don't think it improves readability, since it doesn't occur in 
arbitrary contexts. It'll always be the only thing on the line.
I think that example is close to the best case, but

bool isOdd(int x) { return x & 1; }

is not terribly difficult to read.
So all you're doing is saving 6 characters + one space.
The longer the return expression becomes, the less it matters.

real isComplicated(int param1, Foo param2, real param3) => 43.4 * 
foo(param2, bar(param2, param1 + param3 * param3,), 556.4 * param1) + 
param3 + param1 *param2 * param2.baz(param1 + 46, param1*2.46);

doesn't look any more readable than the equivalent code with a return 
statement. Especially not in the member function case.
Dec 29 2011
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2011-12-29 10:19, Don wrote:

 On 28.12.2011 17:41, Jacob Carlborg wrote:

 On 2011-12-27 23:27, Timon Gehr wrote:

 On 12/27/2011 05:25 AM, Andrei Alexandrescu wrote:

 https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc





 Andrei


 Great! =)

 What about making => syntax available to named functions as well?

 class C{
 private int x;
 int getX() => x;
 }


 void main(){
 int[] arr;
 bool isOdd(int x) => x&1;
 writeln(arr.filter!isOdd());
 }


 I wouldn't say no to that.


 I don't think it improves readability, since it doesn't occur in
 arbitrary contexts. It'll always be the only thing on the line.
 I think that example is close to the best case, but

 bool isOdd(int x) { return x & 1; }

 is not terribly difficult to read.
 So all you're doing is saving 6 characters + one space.
 The longer the return expression becomes, the less it matters.

 real isComplicated(int param1, Foo param2, real param3) => 43.4 *
 foo(param2, bar(param2, param1 + param3 * param3,), 556.4 * param1) +
 param3 + param1 *param2 * param2.baz(param1 + 46, param1*2.46);

 doesn't look any more readable than the equivalent code with a return
 statement. Especially not in the member function case.


When you're implementing a lot of properties that basically just 
forwards to the instance variables it can be really useful.

-- 
/Jacob Carlborg
Dec 29 2011
next sibling parent reply =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 29-12-2011 14:07, Jacob Carlborg wrote:

 On 2011-12-29 10:19, Don wrote:

 On 28.12.2011 17:41, Jacob Carlborg wrote:

 On 2011-12-27 23:27, Timon Gehr wrote:

 On 12/27/2011 05:25 AM, Andrei Alexandrescu wrote:

 https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc






 Andrei


 Great! =)

 What about making => syntax available to named functions as well?

 class C{
 private int x;
 int getX() => x;
 }


 void main(){
 int[] arr;
 bool isOdd(int x) => x&1;
 writeln(arr.filter!isOdd());
 }


 I wouldn't say no to that.


 I don't think it improves readability, since it doesn't occur in
 arbitrary contexts. It'll always be the only thing on the line.
 I think that example is close to the best case, but

 bool isOdd(int x) { return x & 1; }

 is not terribly difficult to read.
 So all you're doing is saving 6 characters + one space.
 The longer the return expression becomes, the less it matters.

 real isComplicated(int param1, Foo param2, real param3) => 43.4 *
 foo(param2, bar(param2, param1 + param3 * param3,), 556.4 * param1) +
 param3 + param1 *param2 * param2.baz(param1 + 46, param1*2.46);

 doesn't look any more readable than the equivalent code with a return
 statement. Especially not in the member function case.


 When you're implementing a lot of properties that basically just
 forwards to the instance variables it can be really useful.


+1.

- Alex
Dec 29 2011
parent =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 29-12-2011 14:10, Alex Rønne Petersen wrote:

 On 29-12-2011 14:07, Jacob Carlborg wrote:

 On 2011-12-29 10:19, Don wrote:

 On 28.12.2011 17:41, Jacob Carlborg wrote:

 On 2011-12-27 23:27, Timon Gehr wrote:

 On 12/27/2011 05:25 AM, Andrei Alexandrescu wrote:

 https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc







 Andrei


 Great! =)

 What about making => syntax available to named functions as well?

 class C{
 private int x;
 int getX() => x;
 }


 void main(){
 int[] arr;
 bool isOdd(int x) => x&1;
 writeln(arr.filter!isOdd());
 }


 I wouldn't say no to that.


 I don't think it improves readability, since it doesn't occur in
 arbitrary contexts. It'll always be the only thing on the line.
 I think that example is close to the best case, but

 bool isOdd(int x) { return x & 1; }

 is not terribly difficult to read.
 So all you're doing is saving 6 characters + one space.
 The longer the return expression becomes, the less it matters.

 real isComplicated(int param1, Foo param2, real param3) => 43.4 *
 foo(param2, bar(param2, param1 + param3 * param3,), 556.4 * param1) +
 param3 + param1 *param2 * param2.baz(param1 + 46, param1*2.46);

 doesn't look any more readable than the equivalent code with a return
 statement. Especially not in the member function case.


 When you're implementing a lot of properties that basically just
 forwards to the instance variables it can be really useful.


 +1.

 - Alex


It would be hard to specify in/out for such properties though, with the 
=> syntax (this is something I do often).

- Alex
Dec 29 2011
prev sibling parent bearophile <bearophileHUGS lycos.com> writes:
Jacob Carlborg:


 When you're implementing a lot of properties that basically just 
 forwards to the instance variables it can be really useful.


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

Bye,
bearophile
Dec 29 2011
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 12/29/2011 10:19 AM, Don wrote:

 On 28.12.2011 17:41, Jacob Carlborg wrote:

 On 2011-12-27 23:27, Timon Gehr wrote:

 On 12/27/2011 05:25 AM, Andrei Alexandrescu wrote:

 https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc





 Andrei


 Great! =)

 What about making => syntax available to named functions as well?

 class C{
 private int x;
 int getX() => x;
 }


 void main(){
 int[] arr;
 bool isOdd(int x) => x&1;
 writeln(arr.filter!isOdd());
 }


 I wouldn't say no to that.


 I don't think it improves readability,
 since it doesn't occur in
 arbitrary contexts. It'll always be the only thing on the line.


I think it does, certainly as soon as there are multiple short 
functions. In case the function is used for code generation, it can get 
rid of one level of indentation.

bool isOdd(int x)  { return x & 1; }
bool isEven(int x) { return !isOdd(x); }
bool isPrime(int x){ return x in primes; }

string generate(string x){
     return mixin(X!q{
          (x) = 2;
     });
}

vs

bool isOdd(int x)   => x & 1;
bool isEven(int x)  => !isOdd(x);
bool isPrime(int x) => x in primes;

string generate(string x) => mixin(X!q{
      (x) = 2;
});



 I think that example is close to the best case, but

 bool isOdd(int x) { return x & 1; }

 is not terribly difficult to read.
 So all you're doing is saving 6 characters + one space.


I think it improves both readability and uniformity. Currently we have

         (){...} // anonymous function
void foo(){...} // named function
         () => ...;  // anonymous function

It would make sense to also allow

void foo() => ...; // named function



 The longer the return expression becomes, the less it matters.

 real isComplicated(int param1, Foo param2, real param3) => 43.4 *
 foo(param2, bar(param2, param1 + param3 * param3,), 556.4 * param1) +
 param3 + param1 *param2 * param2.baz(param1 + 46, param1*2.46);

 doesn't look any more readable than the equivalent code with a return
 statement. Especially not in the member function case.


My intention is that it would be used with short expressions. Such 
monster expressions as in your example are rare in real world code.
Dec 29 2011
parent reply Don <nospam nospam.com> writes:
On 30.12.2011 01:13, Timon Gehr wrote:

 On 12/29/2011 10:19 AM, Don wrote:

 On 28.12.2011 17:41, Jacob Carlborg wrote:

 On 2011-12-27 23:27, Timon Gehr wrote:

 On 12/27/2011 05:25 AM, Andrei Alexandrescu wrote:

 https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc






 Andrei


 Great! =)

 What about making => syntax available to named functions as well?

 class C{
 private int x;
 int getX() => x;
 }


 void main(){
 int[] arr;
 bool isOdd(int x) => x&1;
 writeln(arr.filter!isOdd());
 }


 I wouldn't say no to that.


 I don't think it improves readability,
 since it doesn't occur in
 arbitrary contexts. It'll always be the only thing on the line.


 I think it does, certainly as soon as there are multiple short
 functions. In case the function is used for code generation, it can get
 rid of one level of indentation.



 string generate(string x) => mixin(X!q{
  (x) = 2;
 });


That just makes it look even more like Perl. The return statement is not 
the problem.


 I think that example is close to the best case, but

 bool isOdd(int x) { return x & 1; }

 is not terribly difficult to read.
 So all you're doing is saving 6 characters + one space.


 I think it improves both readability and uniformity. Currently we have

 (){...} // anonymous function
 void foo(){...} // named function
 () => ...; // anonymous function

 It would make sense to also allow

 void foo() => ...; // named function



 The longer the return expression becomes, the less it matters.

 real isComplicated(int param1, Foo param2, real param3) => 43.4 *
 foo(param2, bar(param2, param1 + param3 * param3,), 556.4 * param1) +
 param3 + param1 *param2 * param2.baz(param1 + 46, param1*2.46);

 doesn't look any more readable than the equivalent code with a return
 statement. Especially not in the member function case.


 My intention is that it would be used with short expressions. Such
 monster expressions as in your example are rare in real world code.


That's my point. The BEST CASE is that you save 6 characters, on 
something which was already easy to read. I don't think it buys you 
anything in readability. Really, nothing at all.
Dec 31 2011
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 12/31/2011 12:51 PM, Don wrote:

 On 2011-12-27 23:27, Timon Gehr wrote:

 In case the function is used for code generation, it can get
 rid of one level of indentation.
 string generate(string x) => mixin(X!q{
  (x) = 2;
 });


 That just makes it look even more like Perl. The return statement is not the
problem.


The indentation is the problem. If you don't like  (x) = 2; then that is 
an unrelated issue.


 My intention is that it would be used with short expressions. Such
 monster expressions as in your example are rare in real world code.


 That's my point.


On the contrary. The longer the expression, the less it buys you in 
readability/the less typing it saves.


 The BEST CASE is that you save 6 characters, on


This is the worst case, if it is applicable. The best case is saving an 
unbounded amount of characters.


 something which was already easy to read. I don't think it buys you
 anything in readability. Really, nothing at all.


Those 6 characters are probably the majority of the characters in the 
function body. It saves you more than 6 characters. It saves you 6 
characters _every time_. For 10 short functions, it saves 60 characters. 
For 100 short functions, it saves 600 characters, etc.

We should probably stop that discussion soon, because there is no 
objective readability measure and therefore it is unlikely that one of 
us will change his opinion.

Anyway, it certainly improves language uniformity. Is there any case to 
be made against generalizing => ?
Dec 31 2011
parent reply Don <nospam nospam.com> writes:
On 31.12.2011 16:58, Timon Gehr wrote:

 On 12/31/2011 12:51 PM, Don wrote:

 On 2011-12-27 23:27, Timon Gehr wrote:

 In case the function is used for code generation, it can get
 rid of one level of indentation.
 string generate(string x) => mixin(X!q{
  (x) = 2;
 });


 That just makes it look even more like Perl. The return statement is
 not the problem.


 The indentation is the problem. If you don't like  (x) = 2; then that is
 an unrelated issue.


It's related. That example is polishing a turd.
BTW the bit I don't like isn't the  (x) -- that's the best bit! It's the 
"mixin(", the "q{", and the "})".




 My intention is that it would be used with short expressions. Such
 monster expressions as in your example are rare in real world code.


 That's my point.


 On the contrary. The longer the expression, the less it buys you in
 readability/the less typing it saves.


 The BEST CASE is that you save 6 characters, on


 This is the worst case, if it is applicable. The best case is saving an
 unbounded amount of characters.


How ??? Each instance of => saves you 6 characters, right?


 We should probably stop that discussion soon, because there is no
 objective readability measure and therefore it is unlikely that one of
 us will change his opinion.


Before the introduction of =>, I never heard anyone mention about the 
"problem" you're fixing. It seems to be a solution in search of problem. 
You can objectively search the newsgroup.


 Anyway, it certainly improves language uniformity. Is there any case to
 be made against generalizing => ?


Yeah.
(1) *Everything* comes at a cost. It needs to provide a genuine benefit.
More importantly:
(2) I do not agree at all that it improves language uniformity. The fact 
that you have to provide a name when declaring a function means it's not 
the same situation at all.
A function literal is an expression. A function is a declaration. The 
contexts when you use them are completely different. And the grammer is 
different.

It means almost-identical function definitions have completely different 
syntax. This reduces uniformity, and reduces readability.
Jan 01 2012
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 01/01/2012 04:39 PM, Don wrote:

 On 31.12.2011 16:58, Timon Gehr wrote:

 On 12/31/2011 12:51 PM, Don wrote:

 On 2011-12-27 23:27, Timon Gehr wrote:

 In case the function is used for code generation, it can get
 rid of one level of indentation.
 string generate(string x) => mixin(X!q{
  (x) = 2;
 });


 That just makes it look even more like Perl. The return statement is
 not the problem.


 The indentation is the problem. If you don't like  (x) = 2; then that is
 an unrelated issue.


 It's related. That example is polishing a turd.


I disagree.


 BTW the bit I don't like isn't the  (x) -- that's the best bit! It's the
 "mixin(", the "q{", and the "})".


That does not commonly appear in Perl code ;). Anyway, your argument 
against => is that you don't like creative use of the language to be 
supported?


 My intention is that it would be used with short expressions. Such
 monster expressions as in your example are rare in real world code.


 That's my point.


 On the contrary. The longer the expression, the less it buys you in
 readability/the less typing it saves.


 The BEST CASE is that you save 6 characters, on


 This is the worst case, if it is applicable. The best case is saving an
 unbounded amount of characters.


 How ??? Each instance of => saves you 6 characters, right?


auto x() => q{
     // 1st line
     // 2nd line
     // 3rd line
     // ...
     // nth line
};


 We should probably stop that discussion soon, because there is no
 objective readability measure and therefore it is unlikely that one of
 us will change his opinion.


 Before the introduction of =>, I never heard anyone mention about the
 "problem" you're fixing.


There does not need to be a problem to perform further improvements. 
Before the introduction of => there also was no precedent of being able 
to replace {return exp;} by => exp in the language.


 It seems to be a solution in search of problem.
 You can objectively search the newsgroup.


Before the introduction of =>, there was no uniformity problem. I am 
sure this will be brought up again at some point in the future.


 Anyway, it certainly improves language uniformity. Is there any case to
 be made against generalizing => ?


 Yeah.
 (1) *Everything* comes at a cost. It needs to provide a genuine benefit.


It requires some trivial parser changes. And I think it does provide a 
genuine benefit.


 More importantly:
 (2) I do not agree at all that it improves language uniformity. The fact
 that you have to provide a name when declaring a function means it's not
 the same situation at all.
 A function literal is an expression. A function is a declaration.


A function literal is the conflation of a function declaration and a 
symbol lookup. It is both a declaration and an expression.


 The contexts when you use them are completely different.


No. Every function literal can be replaced by a function definition and 
a symbol lookup. And every function definition can be replaced by a 
function literal.



 And the grammer is different.


That is the point. The grammar should be the same, as it was before the 
introduction of =>.


        (int x){return x&1;}
        (int x) => x&1;
int foo(int x){return x&1;}
int foo(int x) => x&1;



 It means almost-identical function definitions have completely different
 syntax. This reduces uniformity, and reduces readability.


The same argument could be made against introducing => delegate syntax. 
I don't think it is a valid point.
Jan 01 2012