A question about move() and a rant about shared

[Dmitry Olshansky]

25-Jan-2014 02:13, Stanislav Blinov пишет:
> On Friday, 24 January 2014 at 19:54:31 UTC, Dmitry Olshansky wrote:
>> If I understand the current direction is to go with ref T and make
>> some language
>> level/compiler level changes to the escaping reference.
>
> Escaping... where? By "go with ref T" you mean return value of e.g.
> front()?

Say front returns a reference to a first element in an array.
Say user stores &someArray.front as pointer somewhere, and the does
someArray.insert([1,2,3,4,5]);
In case array got resized the pointer is now dangling. Sealed containers 
were meant to prevent such class of errors entirely.

Other links:
http://forum.dlang.org/thread/bug-5541-3@http.d.puremagic.com/issues/
https://github.com/D-Programming-Language/dmd/pull/1903
>
>>> struct Packet {
>>>     ulong ID;
>>>     ubyte[32] header;
>>>     ubyte[64] data;
>>> }
>>>
>>> Note that I do have arrays in there, but they cannot possibly
>>> introduce any aliasing, since they're static.
>>
>> They can. To copy the thing out of somewhere you need to reach into
>> memory area  that is shared between threads and then all bets are off.
>> //Example:
>> shared Packet[4] buffer;
>
> Aha, I see you responded as you went through my post :) I've got this
> case covered further down. Of course they can this way. But
> instantiating them as "shared" doesn't make sense anyway, exactly
> because they are not "shared"-aware.

It makes sense as in memory being visible from many threads.
E.g. buffer[0].ID is accessible via atomic CAS operation. Same with 
header and data fields.

>> High level invariants that deal with ownership are not represented in
>> D typesystem and hence exist only in the head of people writing
>> code/comments and better be encapsulated in something manageable.
>
> But they actually are. immutable === doesn't care: share or own, you
> only ever can read it.

> Value type === single owner.

No. You may have many pointers to one shared value type.
And most certainly not '==='.

Anyway I was talking about ownership as in objects that own other objects.
See for example these 2:
http://bartoszmilewski.com/2009/09/22/ownership-systems-against-data-races/
http://bartoszmilewski.com/2009/06/02/race-free-multithreading-ownership/

> Because you can only
> ever give away the value entirely (move() it) or a copy of it (which is
> coincidentally both shallow and deep copy).
> References (any kind
> thereof) === sharing. Granted, this system is lacking (i.e. it'd be nice
> to have unique references). But that's at least a bare base.
>

And that's the center point. D's type system doesn't statically ensure 
if there are references present or not. And shared just implies "may be 
referenced from many threads" and local/mutable is "may be referenced 
from current thread". Not a single thing in the D type system makes sure 
e.g. that unique value has exactly one reference to it.

See e.g. Rust where authors introduce such notion in the type system.

-- 
Dmitry Olshansky