Proposal request: explicit propreties

[Lionello Lunesu]

Ary Borenszweig wrote:
> The problem is, the user can use them as functions or as properties. 
> This is ok from the compiler point of view, but the code looks ugly if 
> it doesn't make sense, like:
> 
> writefln = 5;

Code that doesn't make sense is always ugly.

Furthermore, I think that particular case can be fixed without removing 
the current syntax by limiting it's scope to functions with a single 
argument.

> Further, if you want a function to be only used with property syntax, 
> you can't. Why would you wan't that? Because if you have
> 
> class Foo {
> 
>   int property() {
>     //
>   }
> 
> }
> 
> and then you decide to change it to
> 
> class Foo {
> 
>   int property;
> 
> }
> 
> for some reason, code that used Foo.property() won't compile anymore.

The whole point of property is that you can simply leave it as a 
function and the compiler will inline it if it turns out to be a trivial 
get/set. You're reasoning here is the wrong way around.

> Finally, there is another reason for wanting to mark functions as 
> properties: when you do autocompletion in an IDE, and it suggests you a 
> function, it can't know whether to autocomplete it as a function or as a 
> property. A solution could be writing something in the ddoc of that 
> function, but since there's no standard for this, each IDE will invent 
> it's own.

This I don't get. Whether you want dummy "()" or not sounds like a 
style, much like space vs. tab, or tab size. IDE's can make it a user 
setting.

> Of course, this is not backwards compatible, so it should be a D2 feature.
> 
> What do you think?

I like the current "implicit getter/setter" very much and think it's one 
of the nicest features of D!

L.