Weird template error

[Nick Sabalausky]

"Michel Fortin" <michel.fortin at michelf.com> wrote in message 
news:gg6c9q$1p2r$1 at digitalmars.com...
> On 2008-11-19 12:49:14 -0500, "Denis Koroskin" <2korden at gmail.com> said:
>
>> It's simply broken! You say that empty pair of parens is equivalent to 
>> none of them and thus it is allowed to omit them, but it's not true at 
>> all. There are lots of examples where "auto foo = bar();" != "auto foo = 
>> bar;" and "auto foo = obj.bar();" != "auto foo = obj.bar;" (delegates, 
>> class/struct instances with overloaded opCall, etc).
>
> As much as I like the no-parens function call syntax, I have to agree with 
> you: it bring inconsistencies.
>
>> - such a duality is confusing (when may you omit the parens and when you 
>> may not?)
>
> Where it becomes confusing is where you try to call the return value of a 
> function, or a no-argument function template. While the most common case 
> (simple function call) may be working right, the no-parens function call 
> syntax creates many not-so-rare corner case we have to deal with. Those 
> cases make it confusing.
>
>> - it makes the language more complex (rules are so complex that hardly 
>> anyone fully understands them)
>
> I don't think each rule for each callable type is in itself that complex, 
> but mixing them leads to complexity.
>
>> - it leads to code inconsistency (half of the programmers remove an 
>> "extra" pair of parens and other half preserve them)
>
> Indeed. I don't think it's bad in itself to have two ways to write 
> something. After all, you can call directly someStruct.opAdd if you prefer 
> that to writing "+".
>
> The problem is that in some cases (function pointers, delegates, opCall) 
> it changes the meaning while in other (plain function) it means the same 
> thing. That's inconsistent, it prevents interchangability between those 
> types, and it becomes confusing when using them together.
>

That's why I like the consistency other languages have of:
- With parens: Invoke function
- Without parens: Refer to function itself

Example of preferred syntax:

class Beeper
{
    void beep() {...}
}

void main()
{
  auto beeper = new Beeper();

  // Beep
  beeper.beep();

  // Make a beeping delegate
  auto dgBeep = beeper.beep;

  // Beep twice later
  doLater(dgBeep);
  doLater(beeper.beep);

  //Error: doLater expects "void delegate(void)", not "void"
  doLater(beeper.beep());
}

>> - it is a source of many compiler bugs (this and lots of related ones)
>
> I'm not sure having bugs in the compiler is a valid argument against the 
> syntax. Creating a whole new property syntax is bound to have bugs too.
>
>> - it contributes to user code bugs that are hard to find at times ("oops, 
>> I missed a pair of parens. God, I thougth that they were optional").
>
> Indeed.
>
> So as I said above, I agree that no-parens function calls make the 
> language inconsistant. I still like it because I find it aesthetically 
> pleasing and because it simplifies the concept of properties by making 
> them simple function calls, but at the same time I'm quite annoyed by the 
> inconsistencies.
>
> -- 
> Michel Fortin
> michel.fortin at michelf.com
> http://michelf.com/
>