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

[Ola Fosheim Grøstad]

On Tuesday, 12 November 2019 at 08:41:52 UTC, Sebastiaan Koppe 
wrote:
> I would personally look at the conflation of dynamic arrays and 
> slices. If you could somehow separate the 2 concepts and THEN 
> constrain slices to only be able to shrink, that might work. 
> (or keep them conflated but make borrowed slices non 
> appendable.) (or make the implicit explicit by somehow 
> requiring `.array` before appending).
>
> On the other hand, the fact that they are conflated also brings 
> benefits, and you certainly don't want to loose them. It is a 
> tough nut to crack.

I'm starting to think that the issue is not that they are 
conflated, but that it isn't clear whether "dynamic" GC arrays  
are values/object, high-level/low-level or 
language-constructs/runtime-constructs.

If concatenation expressions work with high-level values 
conceptually, and slices are views on those values, and GC-arrays 
are high-level-nonruntime-constucts, then things might become 
more clear.

Then leave to the optimizer to estimate and preallocate a buffer 
size (or with hints).

I don't think there is anything wrong with having high level 
concepts, but then they should be truly high level so that the 
optimizer can do the work and there should be some clear 
delineation between high-level and  low-level types. (You could 
still allow low level operations temporarily, but the life-time 
of that would have to be made formal, so that the optimizer has 
free hands when the low-level work is done).

But then you also need another low-level concept for views on an 
address-bound object/buffer/memory.

So it is a tough nut, yes.


> In general I agree with the sentiment D's language features 
> oftentimes depend too much on an all-knowing garbage collector.

Yes, but is also cultural, in the sense that some people rely 
100% on the garbage collector. So how can  the type system ensure 
that the high quality libraries they write are usable in the more 
general programming context?

If all programmers only relied on the GC by 30%, then maybe this 
would be less of an issue, as they would think differently about 
the use context of the library.  The rather weakly typed C++ 
ecosystem works because there is some shared understanding of the 
use context and conventions.

So that is an extra challenge for D. Maybe static analysis could 
help. Some innovation that can prove properties down the call 
chain fromt he call site (rather than all those attributes on the 
function signatures).