A nice way to step into 2012

Don nospam at nospam.com
Sun Jan 1 07:39:20 PST 2012


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.


More information about the Digitalmars-d mailing list