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

[Ola Fosheim Grøstad]

On Tuesday, 12 November 2019 at 11:12:30 UTC, Jonathan M Davis 
wrote:
> Dynamic arrays and manually managed memory are a _terrible_ 
> combination, because dynamic arrays do nothing to manage 
> lifetimes. They're really not any different from passing naked 
> pointers around as far as lifetime tracking goes. This means 
> that the only way that you can automatically manage that is to 
> restrict where they can be stored. scope does that, but the 
> result is that you can pretty much just pass the data into a 
> function that operates on it and doesn't store it.

One option, albeit unorthodox, is to require heap-stored slices 
to be "concrete" and therefore "encode" the properties of what it 
is referencing.

Whereas you could allow slices used in the call-graph to be 
"abstract" (templated, but without the syntax) and then infer 
their concrete properties using static analysis.

So, the counter-argument would be "combinatorial explosion", but 
if the compiler deduce that the actual function that is being 
compiled generate the same code for a set of concrete slice types 
then you can emit a single copy of the compiled code.

Anyway, that ought to be sufficient to distinguish GC, reference 
counted and RAII objects. And it would also allow D slices to 
differ from C++ slices, but also allow you to write one function 
to cover both scenarios.