Possible @property compromise

[Rob T]

On Wednesday, 30 January 2013 at 00:25:41 UTC, Jonathan M Davis 
wrote:
>
> 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

I agree partial emulation can work, and I see you've pointed out 
that the usage of a property will have to be restricted so that 
it can work, but this means you have to mark your naked variables 
as @property ahead of time, otherwise you'll discover that you 
cannot replace a naked variable with a property without doing 
plenty of re-work.

Given that we won't be able to drop in a property without rework 
unless preplanned ahead of time, I'm not so sure we'll be gaining 
anything new here with specially marked properties, and even if 
we could drop them in, I'm still not sure it's a big gain.

I can see some value I suppose if you can mark a naked variable 
as @property because you know it will likely be wrapped into a 
function call later but don't want to implement the wrappers 
immediately, but I don't know if that's something a lot of people 
really need or care that much about.

I find the discussion we're having in another thread on the 
possibility of using a struct-like implementation for gaining 
property-like behaviors much more compelling a change for D 
because it extends D with interesting ways to implement variables 
and functions that can be used in more generalized situations AND 
it solves the property implementation issues too (in similar 
"restricted" ways as you've suggested can be done).

See last few posts ...
http://forum.dlang.org/thread/kdukid$stg$1@digitalmars.com

If we can not only implement @property as hoped for, but also get 
more expressive language features introduced along with it, then 
it may be something worth doing.

--rt