On Wednesday, August 17, 2011 13:31 Martin Nowak wrote: > Not wanting to drift too far off topic I'll add one last point. > given: > immutable(int[]) data = assumeUnique(myints); > send(cast(int[])data); > writeln(data[0]); > > A compiler implementation could deduce data won't change between > initialization and the write. > Thus performing optimizations that would break the code. > I think that and being able to store ctfe data in read only sections are > the reasons for the undefined behavior. > Removing Immutable With A Cast => > http://www.digitalmars.com/d/2.0/const3.html
Yes, because you actually kept the data on the original thread. The _only_ way that passing via send by casting to and from share or to and from immutable is going to work properly if you _do not keep the data on the original thread_. By casting to either shared or immutable, you're breaking the guarantees that the compiler makes and expects. So, doing something like using that data again on the original thread is broken regardless. The _only_ time that this way of passing mutable data via send is okay is when you're actually passing full ownership of the data across and never touching it on the original thread again (unless you pass it back across the same way, handing over ownership again). Your code is broken regardless of whether you're using immutable or shared. True, immutable might be more thoroughly optimized than shared is therefore more likely to break, but the code is broken regardless. - Jonathan M Davis