Property discussion wrap-up

[Zach the Mystic]

On Wednesday, 30 January 2013 at 17:35:25 UTC, Dmitry Olshansky 
wrote:
>> Okay, cool. Two questions remain: 1) How hard to implement 
>> structs
>> nested in structs to mimic ones nested in functions?
>
>
> IMO if property is to be implemented in the library it has to 
> include the field itself. (And I suspect properties should 
> enjoy compiler support).
>
> Then something like:
>
> struct A{
> 	Property!(int, filter, getter) prop;
> private:
> 	void func()
> 	{
> 		...
> 		prop.raw = xxx; //direct write
> 		prop = yyy; //goes through setter
> 	}
> }
>
> where .raw is the field itself and there must be a way to let 
> only struct itself have access to it. I have one method to get 
> this but I don't like it - put this in each module:
>
> mixin PropertyForModule!(my_module);
>
> introducing a Property template in this module, with private 
> .raw accessible thusly only in this module.
>
> Getter is then just any function that maps T => T, with x => x  
> by default so can be omitted.
>
> Filter is something new but in essence it works like the 
> following setter:
>
> void setter(T)(ref T val, T newVal)
> {
> 	val =  filter(newVal); //filter may through
> }
>
> It's a bit more restrictive though so feel free to destroy.

Does my suggestion about the compiler detecting a struct with no 
data warm you up a bit to properties as structs? If so, there is 
really very little need for ANY library support. Strangely, 
implementing struct-nested structs with actual data could be a 
significantly harder task than implementing them with no data. No 
extra pointer need be created.

I'll try to summarize the changes required. The first two are 
necessary. The third is for aesthetic reasons, but as in the case 
of lambda functions that could make a huge difference.

1. Have non-static struct-nested structs be able to refer to 
their parent's data. With no-data structs, I suspect this will be 
easy, and it's actually the primary intended usage, which makes 
only the corner case tricky, where new pointers must be added, 
etc.

2. Add opGet to the compiler's list of overloads. It is simply 
opCall but with parens banned instead of mandated.

3. Enable Highlander structs so that defining a property is as 
easy as define a new-style lamba:
struct __fooHidden {}
__fooHidden foo;

simply becomes:

foo struct {}