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/[email protected]/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...
