Re: Possible @property compromise

[TommiT]

On Friday, 1 February 2013 at 04:22:51 UTC, Zach the Mystic wrote:
On Friday, 1 February 2013 at 03:39:19 UTC, TommiT wrote:
On Friday, 1 February 2013 at 03:13:42 UTC, Zach the Mystic 
wrote:
On Friday, 1 February 2013 at 02:27:30 UTC, TommiT wrote:
And here's another example of why it is as big of a problem 
as I make it sound to be:

import std.concurrency;

struct Array
{
 int _len;

 length struct // Using Zach's syntax
 {
     @property get() { return _len; }
     alias this = get;
     void opAssign(int rhs) { _len = rhs; }
 }
}

void func(T)(T t)
{
 auto v = t;
 v = 10;
}

void main()
{
 Array arr;
 spawn(&func!int, arr.length);
 arr.length = 20; // And here we have a data-race.
                  // Good luck trying to find these
                  // kinds of bugs.
}

I'm sorry, I know very little about race conditions. If you 
might explain just a little bit about what is happening here, 
I'd be in a better position to understand what you're saying. 
I really can't say anything other than please describe what 
this does and why it's a problem at this time.

spawn(&func!int, arr.length);

...creates a new thread and runs the following function call 
in it:
func!(int)(arr.length)

While that function call is evaluating in the new thread, the 
old thread may simultaneosly execute:
arr.length = 20;

Since both of those threads end up at some point calling 
arr.length.opAssign and therefore both of them may assign to 
arr._len simultaneously, that's a data-race. It would be 
data-race also if only one of them wrote to it and the other 
one just read it.

I'm familiar with the fact that programmers face endless woes 
with regard to data-races. I thought that D has unshared data 
by default. But since Array arr is defined in main instead of 
outside main, therefore it is sharable between the two threads? 
If two threads have access to the same data, what makes length 
as a property different from length as an int? This problem may 
be over my head for now...

Actually, that example of mine was wrong - it's not a data-race. 
I failed to notice that in:
spawn(&func!int, arr.length);
...arr.length is actually converted to int using alias this. My 
bad.

Now I'm going to repeat the "spooky modification at a distance" 
problem I showed earlier, but this time, instead of writing it in 
the new syntax and the new struct behaviour you invented, I write 
it using current D syntax:

import std.concurrency;

struct Array
{
    int _len;

    struct PropType
    {
        Array* _outer; // In your syntax this was implicit

        @property int get()
        {
            return _outer._len;
        }

        alias this = get;

        void opAssign(int rhs)
        {
            _outer._len = rhs;
        }
    }

    PropType length;
}

void func(T)(T t)
    if (isImplicitlyConvertible!(T,int))
{
    // Given that is(T == Array.PropType), then
    // all 3 lines below do the same thing:
    t = 42;
    t.opAssign(42);
    t._outer._len = 42;
}

void main()
{
    Array arr;

    // setting the _outer pointer to the enclosing object:
    arr.length._outer = &arr;

    assert(arr._len == 0);
    func(arr.length); // no conversion to int happening here
    assert(arr._len == 42);
}

So, it's possible to modify arr._len just by passing arr.length 
by value to a function.