Weird template error

[Nick Sabalausky]

"Jarrett Billingsley" <jarrett.billingsley at gmail.com> wrote in message 
news:mailman.59.1227675354.22690.digitalmars-d at puremagic.com...
> On Tue, Nov 25, 2008 at 10:44 PM, Nick Sabalausky <a at a.a> wrote:
>>       // compiler knows that foo.x is an int property
>>       // and turns this:
>>       makeTen(foo.x);
>>
>>       // into this:
>>       auto _foo_x = foo.x;
>>       makeTen(_foo_x);
>>       foo.x = _foo_x;
>>
>>       // and finally this:
>>       auto _foo_x = foo.x.get();
>>       makeTen(_foo_x);
>>       foo.x.set(_foo_x);
>
> I considered this, but what if your setter/getter had some kind of
> side effect?  I know, it's probably a little thing to worry about, but
> still, I would have intuitively expected it to have been evaluated
> each time the ref parameter was accessed in the function instead of
> just once before and after the call.

I thought about that too, but the only realistic examples of that I can 
think of would involve writing getters/setters that abuse the whole point of 
property syntax. I'm not completely certain, but I think this might be an 
issue that's akin to using operator overloading to make '*' peform a 
subtraction. Can anyone think of any non-abusive case where the above would 
fail? Maybe something with threads and synchronization?

Another idea, but possibly messy:
Maybe there could be some automatic behind-the-scenes 
templatization/overloading such that: If there's a function ("bar") that has 
a parameter passed by reference ("x"), and you try to pass "bar" a property 
(of the correct type), then an overloaded version of "bar" is created which 
replaces accesses to x with calls to x's getter/setter.

Ie:

void bar(inout int x)
{
    x = x + 2;
}

void main()
{
   int i;
   auto foo = new Foo();
   bar(i);

   bar(foo.x);
   // When the compiler detects the above line,
   // it generates the following overload of bar:
}

// Automatically generated by compiler,
// unless "bar(foo.x);" above is commented out.
void bar(inout property!(int) x)  // "property!(T)" is either built-in or 
part of the core library
{
    x.setter(x.getter() + 2);
}

Although, I suppose that might still create an excess of extra functions 
when using dynamically-linked libraries (or maybe not, because it would 
probably only be needed on inout params, and I don't think it's common to 
have a large number of those).