On 5/12/15 12:53 PM, Brad Anderson wrote:
On Tuesday, 12 May 2015 at 15:51:38 UTC, Steven Schveighoffer wrote:
The whole concept of immutable being implicitly shareable is kind of
broken. There are many reasons to have immutable unshared data, and it
poisons const to the point where you really should consider any const
variable to be also shared.


What are the extra implications of having to think of all const
variables as shared? I guess it would mean the currently unimplemented
memory barriers should happen for const variables as well. That does
seem like a problem.

The one that always comes to my mind is array appending:

immutable int[] x = new int[5];

const int[] y = x;

x ~= 1; // should this lock;

y ~= 1; // should this lock?

y = new int[5];

y ~= 1; // should this too? If so, isn't it a waste of cycles?

Of course, array appending is an odd duck here, as generally you are not generally able to add data to an immutable piece of data.

But there are other cases. Consider a struct like this:

struct S
{
   int a;
   immutable int b;
}

I can create an S on the heap (or whatever allocator), and s.b could be shared, but s.a could not be. How does that treat the block the entire S is allocated in?

As much as it sucks, I'd prefer to see immutable not be implicitly shared, and require a cast. We could specialize the cast so it's not a true "ignore all the rules" cast. Sharing data is too fraught with danger. A concept of uniqueness would help here too.

I think shared is broken in general, the only thing that's great about it is *not* shared, which is defined by the absence of shared :) That is something that's easy to wrap your head around.

-Steve

Reply via email to