Omittable parens is an evil

[Koroskin Denis]

On Sun, 20 Jul 2008 23:56:26 +0400, Tomasz Sowiñski <tomeksowi at gmail.com>  
wrote:

> downs Wrote:
>
>> bearophile wrote:
>> > Tomasz Sowiñski:
>> >> When coding, at first, I was glad to be able to snip the parens  
>> (makes code look cleaner), but then I came to the same conclusion - the  
>> illusory cleanness of code strikes back in the form of trouble with  
>> telling "something" and "do something" apart.<
>> >
>> > I agree that omittable parens is bad, I always put them.
>> > If parens become compulsive you don't need to use "&somefunc", you  
>> just use "somefunc" to denote the pointer/delegate and "somefunc()" to  
>> call it.
>> >
>> > Bye,
>> > bearophile
>>
>> Seeing as I don't share your opinion on this topic, I humbly submit  
>> that this is not a problem with the language but with the coders,  
>> specifically, people who have used function pointers in C.
>>
>> Since I acquired D before I had much need for that atrocious syntax,  
>> &function has always made more sense to me.
>>
>> Because of this, I do not see a problem with foo or foo() - both are  
>> clearly not the function address.
>
> I think functions should be called thisWay() and function addresses  
> should be obtained &thisWay.
>
> But then we would have the question what should thisWay symbol mean  
> without parens or ampersand? Maybe it shouldn't mean anything? or use it  
> only to pass functions into other functions as arguments? hm...
>
> Tomek

I think it should be used to address to the function itself, like  
typeof(func), func.stringof, func.mangleof, etc.

func() <- function result
&func  <- function pointer
func   <- function itself