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

[Ola Fosheim Grøstad]

On Tuesday, 12 November 2019 at 10:25:40 UTC, Robert Schadek 
wrote:
> Hm, when I think of go I think of docker/kubernetes.
> For me that is systems programming.
> I see your point, but I think there are other ways to look at 
> it.
> You can actually get Microcontrollers that run python not c.

Yep, that is true.

> I think saying, and I'm not saying you say that, systems 
> programming therefore
> mmm is at least a "Hasty Generalization".

Yes.

I think the long term future even for embedded programming is 
high level languages that allows you to "bind" datastructures to 
low level representations where you need them (but otherwise 
leave it to the compiler).

So yes, how to do systems programming will hopefully evolve over 
time.

But for me there ought to be a separation between high level and 
low level constructs. In C++ all high level types are library 
only, that means the compiler can only do low level optimization. 
D has some room to innovate there, so I certainly am sympathetic 
to the idea that high level features should not be undermined. 
Maybe the question ought to be, can the high level features be 
strenghtened in a way that allows the compiler to be smarter and 
that allows the compiler to "understand" where low level 
assumptions are being made and where it has free hands to be 
smart. So rather than downgrading high level construct, upgrade 
them from runtime-constructs to compiler-constructs.

It is quite intriguing though that something as simple as slices 
can be so complex to figure out. I've written some variations of 
slices for C++ before they added it, and there are so many trade 
offs... Maybe one has to classifiy all the different use 
scenarios for slice-like types and then figure out some solution 
that allows the compiler to be more clever than in other 
languages.