Possible @property compromise

[Zach the Mystic]

On Friday, 1 February 2013 at 18:34:01 UTC, Steven Schveighoffer 
wrote:
> I think you are wrong in how you assume a struct works, but not 
> in your attempt to implement properties.  Struct is just not a 
> key to this formula.

I disagree. It is absolutely the fundamental key to this formula.

> Note that many (including myself) consider the overloading of 
> static to be a *detriment*.

I guess there's certainly a matter of taste involved here. Had 
you suggested another keyword, or what had your preferred 
suggested syntax looked like?

> You are applying struct where none is needed.
>
> The current front accomplishes what you have shown except it 
> does not require an actual struct instance (as your code does), 
> and it's far easier to understand and implement than your 
> method.
>
> What you are trying to do is establish a *namespace* in which 
> to declare operator overloads.  The whole idea that it has to 
> be a struct is incorrect, it does not need a "struct" wrapper.
>
> I think you are not understanding how a struct is implemented, 
> and how it's methods are implemented.  A struct function 
> without a 'this' reference is a static struct function.  
> Nothing different from a standard function, except it is in the 
> struct *namespace*.  I think this is what you really are after, 
> a separate *namespace*.
>
> I think *that* idea has merit, and should be examined.  Drop 
> the struct, and you are back to the table.
>
> -Steve

I'm sorry we couldn't find common ground here. I can imagine two 
camps developing, one with your ideas and one with mine. As far 
as a static struct function, how could it get the pointer to its 
enclosing struct, which it needs in order operate on the 
enclosing struct's data?