DIP 1025--Dynamic Arrays Only Shrink, Never Grow--Community Review Round 1

[Dukc]

I'll repeat what I said in the draft review, because I don't know 
whether my feedback wasn't noticed. In addition, I'll be more 
explicit.

In no practical way we can implement this. The breakage would 
most likely dwarf breaking autodecoding.

However, the above only applies to breaking appending to slices 
in general. I agree that if the slice is not either:

1. GC-allocated
2. referring to a static array.
3. referring to an initialization value of an array of `static` 
storage class

...then the chances of somebody appending to it are low enough 
that breaking might be viable. Even then, somebody might append 
to a mallocated slice by GC if there is another reference to the 
original slice lying around, but for me that sounds rare enough 
that finding memory leaks could justify the breakage.

I see two alternatives. We can simply discourage growing slices 
with the garbage collector. A transition switch would be 
introduced, but no removing `~` or `slice.length += 2` totally, 
or at least not for many years. We also could introduce a new 
appending operator, say >< (along with ><=), which behaves just 
like ~ but refuses to work with slices, and encourage to use that 
istead of the present append operator.

The other alternative is that slice growing by GC would check 
where the array is referring to. First, if it refers to null, the 
static memory area or the stack, check passed. Second, if it 
refers to anything the GC controls, check passed. Otherwise, it's 
assumed it's pointing to mallocated memory, or just corrupt - 
program terminated with an unrecoverable error. For @system code, 
the compiler could forgo these checks with the same rules as 
array bounds checks can be forgoed. Growing a slice of mallocated 
memory where the check is omitted would be undefined behaviour.