Uniform Function Call Syntax(UFCS) and @property

[Steven Schveighoffer]

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

> On Thursday, March 03, 2011 12:32:44 kenji hara wrote:
>> It seems to me that you think only combination of member-variable like
>> property and UFCS.
>> My suggestion is consider global-variable like property as well.
>> example:
>>   @property int global_var(){...}  // getter, int n = global_var;
>>   @property void global_var(int n){...}  // setter, global_var = 10;
>>
>> I think that global variable like setter function and member-variable
>> like getter function occur ambiguity.
>> Getter and Setter are the opposite meaning.
>
> I'd strongly argue that global/module properties make no sense. What are  
> they a
> property of? The module? The whole idea with properties in the first  
> place was to
> be an abstraction of member variables. And since you really shouldn't be  
> using
> mutable global/module variables anyway, the benefit of such a "property"  
> is
> already limited. And if they cause ambiguity (as they obviously do),  
> then that's
> one more reason to disallow them.

I think global properties are certainly valid.  You can have a global  
field, why not a global property?

The classic example is a singleton:

class Singleton
{
    private this() {}  // disable public construction
    private Singleton _instance;
    @property public static Singleton instance() {if(!_instance) _instance  
= new Singleton; return _instance;}
}

Note that instance has no 'this' pointer.  However, it obviously does not  
have the ambiguities of UFC properties.  However, I find the statement  
that a property must be a member variable very incorrect.

I am sure there are good use cases for global (TLS) variables that are  
properties.  In fact, I use one in druntime.  The LRU cache for array  
appending is a per-thread array, and it *must* be allocated outside any  
scannable location (not in TLS or GC heap).  Therefore, I malloc it.   
However, I malloc it on the first append.  But this is hidden by a  
property.

The main reason for doing it this way is because originally it was stored  
in TLS as a fixed-size array.  However, that meant any cached memory  
blocks that were appended to would be kept in memory by the cache.  I used  
the fixed array directly in many places in the file, so the easiest change  
was to make it a property.  It works quite well actually.  If we can ever  
mark sections of TLS as non-scannable, then I can easily change it back  
 from a property to a field.

See  
https://github.com/D-Programming-Language/druntime/blob/master/src/rt/lifetime.d#L382

-Steve