A question about move() and a rant about shared

[Stanislav Blinov]

On Saturday, 25 January 2014 at 11:51:04 UTC, Dmitry Olshansky 
wrote:

>> 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

Aha, got it. Thanks, I'll be looking into that.

>> I've got this case covered further down. Of course they can 
>> [introduce aliasing] 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.

Yup, but that's not the case with Queue, as I hope is already 
established in my previous reply.

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

Pointers are references. Whatever one thread does with pointers 
to its own data is its business and has nothing to do with D's 
"shared" qualifier. Yes, it's sharing too, only it's not meant in 
the context "shared between threads".
I didn't talk about ownership as in "one object owns another". I 
was talking about ownership of data in the context of threads. 
You cannot share a value type with another thread, unless you 
give it a pointer. And you can't do that in idiomatic D, because 
you're not allowed to "send" a pointer-to-non-"shared" to another 
thread.

> 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/

I've read that :)

>> 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.

I've been having fun with various approaches to implementing 
Unique. I have some ideas on where it can be improved, but 
without language support, this is gruesome indeed.

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

I've never investigated Rust, never hurts to take a look, I 
guess...