Possible @property compromise

[Jonathan M Davis]

On Wednesday, January 30, 2013 00:55:13 Rob T wrote:
> On Tuesday, 29 January 2013 at 23:09:55 UTC, Jonathan M Davis
> wrote:
> [..]
> 
> > If we go any route other than explicit properties, we're giving
> > up on the
> > possibility of being able to swap variables and property
> > functions without
> > breaking code.
> > 
> > - Jonathan M Davis
> 
> Given how D currently works, I don't see how we can realistically
> implement a function as a drop in replacement for a variable and
> expect code to continue working as if nothing had changed.
> 
> One of the bigger problems is that the getter returns by value,
> not ref, so everything that expects a ref return will fail.
> 
> I expect to make precise variable emulation through properties
> will require a lot of compiler magic, and there will be
> inevitable bugs and conflicts that follow. I really don't see
> that there's enough value with the property concept to justify
> the costs of precise variable emulation.
> 
> You know a lot more about implementing compiler magic than I do,
> so I'll ask you if you think the effort is doable enough to
> justify having property functions that can act like a drop in
> replacement for existing variables?

I believe that two main things are needed:

1. Make it possible to mark a variable such that you can't do anything with it 
that you couldn't do with a property function (e.g. taking its address needs 
to be illegal).

2. Add property rewrites to make it so that stuff like ++ and += work.

You'll never get a property function to operate 100% like a variable, but you 
_can_ make it so that it's very close.. C# gets away with making variables and 
property functions swappable because it do stuff like let you take the address 
of a variable or a function. We basically need to do the same by restricting 
variables which are properties and improving the rewrites that the compile 
does for property functions.

- Jonathan M Davis