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).

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.

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.

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.

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.

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.

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)

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.

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 => ?

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.