DIP23 draft: Fixing properties redux

[Zach the Mystic]

On Tuesday, 5 February 2013 at 08:39:15 UTC, Dmitry Olshansky 
wrote:
> On 02/05/2013 02:28 AM, Andrei Alexandrescu wrote:> On 2/4/13 
> 2:04 PM, Jonathan M Davis wrote:
> >> We could save a lot of boilerplate code if we can simply
> make it
> >> variables and
> >> property functions guaranteed to be swappable without
> breaking code.
> >
> > I think this is quite powerful. The way we can do this is by
> making
> > properties emulate a subset of actual variables.
> >
>
> This is the primary real-world proble to solve.
> If tackle it right  we'd secure a sizable flow of Java
> converts simply because of this feature alone ;)
>
> More seriously I believe it's worth noting that properties 
> can't emulate (in principle) exactly one aspect of variable - 
> taking address
> as a pointer. Honestly I can't see a way to overcome it without 
> introducing a user-defined way to impose this restriction on a 
> field of a struct/class.

I'm not really sure which part of my article you are addressing 
here, but allowing  'opAddress' is available as a last resort. 
Also note that I had proposed 'cast(function)' instead of '&' to 
get the top-level function, which, unlike '&', can give: 'Error: 
not castable as a function'

> Then keeping in mind __traits I have the following clause to 
> add to the current proposal:
>
> Inside of aggregate a field marked with @property indicate is 
> semantically equivalent to compiler wrapping it with trivial 
> getter and setter. Example:
> struct Foo{
> @property T x;
> }
>
> treated  semantically as if:
> T __x; // hidden by compiler
> //templated to have deduced safe, pure, nothrow
> @property T x()()inout{ return x; }
> @property void x()(T val){ x = val; }
>
> ---
> Dmitry Olshansky

While I appreciate your responding to my post, I'm a little 
confused which of its points you are addressing here.