Suggestion: properties should be treated as 'virtual members variables'

[Jarrett Billingsley]

"Steve Horne" <stephenwantshornenospam100 at aol.com> wrote in message 
news:7i52g25vn3qkg41uhoako5jmr5135jif0u at 4ax.com...

> D must already be doing some of this. After all, take another look...
>
> : class A {
> :      int prop() {return m_val;}
> :      int prop(int val) {return m_val = val;}
> :
> :      int m_val = 0;
> : }
>
> There is a getter _and_ a setter, so when you write 'a.prop' the
> compiler cannot immediately know which method to use for the delegate.
> The same happens any time you create a delegate from an overloaded
> method, not just for properties. The compiler needs to create a
> generalised 'one-of-these-thingies' semantic object, then resolve it
> from context later.
>
> So why not handle inout parameters?
>
> What am I missing?

I thought about it, and it would require the method that takes the inout 
param to have different implementations.  All an inout parameter really is 
is an implicit address-of.  So when you write:

void foo(inout int x)
{
    x++;
}

int x = 5;
foo(x);

It becomes:

void foo(int* x)
{
    (*x)++;
}

int x = 5;
foo(&x);

When you try to pass a property to it, what happens?  Properties are 
methods, not variables.  They have to be called, they can't just be 
dereferenced.  The inout-taking function can't know whether it's being 
passed a method or a variable, and it has to do different things for both. 
It just can't work.