shared arrray problem

[Charles Hixson via Digitalmars-d-learn]

On 11/19/2016 01:50 PM, ag0aep6g via Digitalmars-d-learn wrote:
> On 11/19/2016 10:26 PM, Charles Hixson via Digitalmars-d-learn wrote:
>> It's worse than that, if they modify the length the array may be
>> reallocated in RAM so that the pointers held by the containing class do
>> not point to the changed values.  (Read the header comments...it's not
>> nice at all.)
>
> Arguably, any D programmer must be aware that appending to a dynamic 
> array potentially means making a copy of the data, and that changes to 
> length are not visible to other views of the data.
>
> But it's an opportunity to mess up, for sure. You could return a 
> wrapper around the array that supports editing the data but not 
> changing the length or appending.
>
> Looks like std.experimental.typecons.Final [1] is supposed to be that 
> wrapper. But in a little test I can still set the length. Not sure if 
> that's a bug, or if Final has slightly different goals.
>
>
> [1] https://dlang.org/phobos/std_experimental_typecons.html#.Final
>
Yes.  I was hoping someone would pop up with some syntax making the 
array, but not its contents, const or immutable, which I couldn't figure 
out how to do, and which is what I really hoped would be the answer, but 
it appears that this isn't part of the syntax.  If the array is 
constant, so is it's contents.  I really *can't* allow the length to be 
changed, and if the array is reallocated, it won't get saved.  But the 
contents of the array are intended to be changed by the calling routines.

Again, for this particular problem the kludge of copying the values into 
the array works fine (and is what I've decided to do), but that's not a 
good general solution to this kind of problem.