Another Properties Proposal

[Chris Nicholson-Sauls]

Chad J wrote:
> Chad J wrote:
>>
>> // baz is just some function. This is on the user's side of the prop.
>> T baz(T)(Bar arg)
>> {
>>   auto ptr = &arg.foo; // foo is a property, a data field works too
>>   T val = *ptr; // calls foo.setFoo(typeof(foo).init);
>>   return val;
>> }
> 
> I just realized that such a thing doesn't work at all, because nothing 
> would expand to the "typeof(foo).init" that is passed to the setter.
> So the idea of returning a delegate from an address-of-property probably 
> isn't useful at all in this context.
> 
> The notion of having the thing returned from address-of-property be 
> something that templates could work with as if it were a data field, at 
> least syntactically, still might have some potential though.  Even 
> better if it doesn't rely on implicit properties.
> 
> In an adjacent post, Chris Nicholson-Sauls suggested that properties 
> could be "treated internally by D as just a struct which calls the 
> self-named function".  Perhaps if such a struct was revealed as some 
> kind of special internal library built in struct then it could be 
> returned as a property's address by default.

I hadn't even thought about the addressing issue when I posted that.  But as you seem to 
say, it might lead to a solution.  The only issue with the design, is that properties 
effectively become a new UD-aggregate type alongside class/struct/union -- which might be 
a benefit sometimes, but might also become yet another thing to consider when writing 
templates.  At the very least, though, we could get a compiler error about missing 
operator overloads if the template did something that wasn't accounted for.  Assuming the 
user wrote the property, he/she could add that operator if its important enough.

Properties whose value is itself an aggregate (including arrays), or a reference, might 
just have their own issues regardless of the design.

-- Chris Nicholson-Sauls