[Issue 10108] Thread local slice to array literal references the same data

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=10108



--- Comment #10 from Igor Stepanov <wazar.leollone at yahoo.com> 2013-05-17 16:25:34 PDT ---
(In reply to comment #9)
> I see. Once again, simplified:
> 
> import core.thread;
> 
> struct Foo {
>     int[] arr;
> }
> 
> Foo[] arr = [Foo([1,2,3])]; // Should have failed? (1)
> 
> void main( ) {
>     int* p = arr[0].arr.ptr;
>     auto thr = new Thread({assert(arr[0].arr.ptr == p);}); // Should have
> failed. (2)
>     thr.start();
>     thr.join();
> }
> 
> In this case, for the assert to fail, we'd have to deep-dup the array (COW
> might make that unnecessary, but that's beside the point).
> 
> This is in a way related to the issue of array literals being mutable, in that
> it is an example of the compiler erroneously assuming some state may be shared
> when in fact it shouldn't.
> 
> I contend that (1) above should simply not compile. It should be required to be
> placed in a module constructor instead. 
Yep
int[] x = [1,2,3]; should not be compiled, but 
shared int[] x = [1,2,3]; //OK
const int[] x = [1,2,3]; //OK, because const is global scope == immutable
immutable int[] x = [1,2,3]; //OK
__gshared int[] x = [1,2,3]; //Same



>A case can be made that the compiler
> should automagically place it in a module constructor for you, but I am not of
> that opinion.
I agree, this is not D way, I think.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------