@property needed or not needed?

Rob T rob at ucora.com
Tue Dec 4 10:02:42 PST 2012


On Tuesday, 4 December 2012 at 16:24:27 UTC, Minas Mina wrote:
> Isn't it possible to have parentheses optional only for UFCS?
>
> E.g.
>
> Allow:
> I 5.writeln
>
> Dissallow:
>
> void f()
> {
> 	writeln("hi");
> }
>
> f; // this currently works
>
>
> I don't know if this is possible to implement.


module main;

void f()
{
	writeln("hi");
}

main.f; // OK or not?

If we're to make the empty braces optional, we have to ask this 
question: What will enforcing the empty braces buy you?

Based on the comments so far, all that it does is tell you at a 
glance that the symbol is a function call. Without the braces 
you'll have to dig a little deeper into the code to figure it 
out. So the () effectively serves the purpose of a naming 
convention for functions. However as was pointed out in this 
thread, there are a few real situations where even with () 
enforcement, you still won't necessarily know what the symbol 
represents without digging into the code, for example if 
@property is enforced. There are arguments in favor of @property 
enforcement, which is to encourage the programmer to think in 
terms of making a function behave like a variable and nothing 
else. It also discourages dropping the () elsewhere. The argument 
against @property enforcement, is that it enforces a coding style 
on the programmer, which may be subjective, and not providing any 
real gain.

What "bad" thing does () enforcement do?

Based the comments, it seems that a lot of people really dislike 
the empty braces when chaining together multiple function calls, 
i.e., it looks ugly and is more effort for apparently no real 
gain, so it does not matter if they are UFCS calls or not, it's 
just ugly when chaining. The arguments against dropping the () 
when chaining, is that you loose the ability to see at a glance 
what is a function call and what is not, although with the 
exception of enforced @property functions.

I think the above sums up the arguments for and against, but 
maybe not.

--rt


More information about the Digitalmars-d mailing list