A few thoughts on std.allocator

[Steven Schveighoffer via Digitalmars-d]

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