Uniform Function Call Syntax(UFCS) and @property

[Steven Schveighoffer]

On Thu, 03 Mar 2011 18:03:48 -0500, Jonathan M Davis <jmdavisProg at gmx.com>  
wrote:

> On Thursday, March 03, 2011 14:07:30 Steven Schveighoffer wrote:
>> On Thu, 03 Mar 2011 16:56:45 -0500, Jonathan M Davis  
>> <jmdavisProg at gmx.com>
>>
>> wrote:
>> > Conceptually, a property makes no sense unless it's a property _of_
>> > something.
>>
>> This is your opinion, not fact.  It is a property of the program/global
>> namespace/module whatever you want to call it.
>
> Per the definition of the word property, a property must be property _of_
> something. Anything else would violate the definition of the word (not  
> that
> programming has ever held itself all that firmly to English  
> definitions). You can
> certainly argue that a global property is a property of a module, at  
> which point
> it _does_ make sense in the sense that it is then a property _of_ the  
> module.
> However, I definitely think that that's pushing it.

I was debating this assumption you have made in making your statement, not  
the statement itself.  Sorry, I sometimes don't express myself very well.

I'll try again:

It is your opinion that modules or classes/structs do not qualify as  
entities to define properties on.  Not a fact.

I disagree completely, and have given several counter-cases.  What do you  
say about the examples, such as the Singleton, or the cache variable I use  
in druntime?

> Regardless, I'd still argue that @property shouldn't be allowed at the  
> module
> level as long as it's going to create ambiguities. And adding extra  
> rules or
> syntax to make it unambiguous as Kenji is suggesting seems like overkill.

I don't disagree that making syntax might be overkill.  But making rules  
that are not consistent doesn't make sense either.  If I have a place I  
can put a variable, I should be also able to put a property there.

Note that there is only one (currently) ambiguous case, the case of a  
getter on an array or a setter on the module.  A setter on an array cannot  
be confused with something else, as well as a getter for the module.

What we need is a syntax to disambiguate.  So essentially, we take the  
most common case, and declare that as the default.  But if you define the  
property this way * then it becomes a property the other way.

Also, keep in mind that I think UFCS should be restricted to builtins only  
(i.e. primitives + arrays, not AA's, since they map to a struct that can  
be customized in druntime).  To provide multiple ways for one to add  
members to classes/structs causes huge ambiguity/hijacking issues.

Just thought of this, I think this might be good enough:

@property(out) denotes a getter on its single argument for functions that  
are at the module level and have one argument:

* if the property is inside a class or struct, then properties with no  
args are always getters, properties with a single arg are always setters.
* if the property is outside a class or struct, and it has no arguments,  
it's a module getter
* if the property is outside a class or struct, and it has one argument,  
it's a module setter (use @property(out) to change it to a getter on the  
first argument)
* if the property is outside a class or struct, and it has two arguments,  
it's a setter on the first argument, as long as that first argument  
supports UFCS.

We could define @property(in) also, and allow the syntax everywhere, but I  
think nobody will ever use it in unambiguous cases.

Other possibilities could be used inside the parens.

-Steve