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

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.

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

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.