Functional programming in D and some reflexion on the () optionality.

[Timon Gehr]

On 08/06/2012 08:05 PM, David Piepgrass wrote:
>  ...
> I'm not sure if I understand your point perfectly, but I definitely feel
> that the way D handles optional parens is awful. The other day I noticed
> that the following is a syntax error (DMD 2.059):
>
> class A { void B() {} }
> auto a = new A().B();
>              // ^ semicolon expected following auto declaration, not '.'
>

Obviously. No clue what this snippet is trying to do.


> Even without silly errors like this, optional parenthesis create
> ambiguities, and ambiguities are bad. Maybe there is a sane way for
> parenthesis to be optional, but the way I've seen D behaving is *bizarre*.
>

Examples?

> The compiler should *expect* parenthesis, and only assume that the
> parenthesis are missing if it's the only way to compile without an
> immediate error. So for example,
> - if foo is a non- at property function that returns another function,
> foo() must invoke foo itself and never the function that foo returns.

This is the case.

> - if I say "&foo" where foo is a non- at property function, it should
> always take the address of the function, never take the address of the
> return value.

This is the case.

> - The rules shouldn't change if you replace "foo" with a complex
> expression like "x.y[z]" or "new Module.ClassName".

If I get this right then this is the case.


If there are any deviations from these rules then they should be filed 
as compiler bugs.