ref returns and properties

[Steven Schveighoffer]

"Andrei Alexandrescu" wrote
> Steven Schveighoffer wrote:
>> There are two possibilities that I can think of.
>>
>> 1. ref return from get, which gets you part-way there.  You can still do 
>> some useful things like which member you are returning getting 
>> calculated, but it doesn't make the call to set when you assign to the 
>> property, or allow calling get multiple times to return different values.
>
> Yah, exactly. One thing I'm rather sad about is that certain containers 
> won't be implementable that way, for example sparse vectors (with most 
> elements zero). A sparse vector would want to return by value from head() 
> and opIndex() (so it can return 0.0 most of the time) and would also want 
> to have control over setting slots. So in brief, sparse vectors won't be 
> supported naturally by our paradigm. They will still be supported, just 
> not in a manner that makes them next to indistinguishable from dense 
> vectors.
>
> Lately I'm getting to think (sour grapes syndrome?) that probably that's a 
> good thing. A sparse vector is very long - e.g. millions of items, and 
> only has a few or a few hundred that are nonzero. It would be wasteful to 
> ever iterate over the whole one million items; I'd rather use a custom 
> algorithm that only "sees" the nonzero elements. It would be nice to have 
> opApply work, but I guess I can live with that too.

A good point.  Let's not forget that the main purpose of ranges being 
special is to support foreach.  Once you start using ranges in different 
ways, then it becomes more of a generalized structure, up to the library 
designer as to how to solve these problems.

>
>> 2. Have a "property delegate", which is like a normal delegate, but 
>> contains 2 functions.  Calling a function which takes such a delegate 
>> makes the compiler generate such a delegate in the case where a simple 
>> lvalue is passed.  You could signify it with the terms "lazy ref" in the 
>> function signature.
>
> Yah, crossed my mind too. With the third function in tow (the one that 
> does the resource acquisition or whatnot) things are getting rather 
> overweight and it starts looking like a full-fledged local class with a 
> vtable and the works might be an option. Local classes have access to the 
> frame pointer of their parent, so probably things can be arranged to work. 
> But the cost of the whole operation becomes too high.

I guess I'm not really sure what the "acquire" method does.  I saw you 
mention it in another post, but with no explanation as to what it actually 
does, just that it was needed.  I'm sure I'm not getting what should be 
obvious, but if you could enlighten, I would appreciate it :)

Having the two functions seems like a reasonable baggage compromise, if you 
want to control the get and set methods of a property and pass that control 
to an underlying function, you need at least that.  If we start generalizing 
it to anything, then it starts looking like struct interfaces would be more 
suitable.  For example, you could allow setting an int property using both 
an int and a string, do you want to pass both setters to a function?  I 
think limiting it to just a set and a get function should be sufficient.

-Steve