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