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

Ola Fosheim Grøstad ola.fosheim.grostad at gmail.com
Mon Nov 11 18:13:45 UTC 2019

On Monday, 11 November 2019 at 17:30:25 UTC, Steven Schveighoffer 
> Sorry, I'm not sure why it's nitpicking. The example shown does 
> not show what the author wanted it to show.

Alright, alright, I thought it was obvious what he meant, but I 
guess that is because I already agreed with his core viewpoint.

> True, GC-using code could be valid to call if it doesn't affect 
> your type. But @nogc IS a valid way to use slices and ensure 
> that they never use the GC to grow.

Yes, but you need to be careful so you don't split the ecosystem 
in two. So people should be able to call the best libraries they 
can find (GC or not).

I understand that this is difficult, but I think the intent of 
this DIP is pointing in the right direction, even if it isn't 
bulletproof or ready.  So I hope it isn't dismissed outright.

> But in fact, a better solution is to make sure the TYPE 
> prevents it

Yes, a type that protects the underlying buffer somehow makes a 
lot of sense.

But then you need to encourage templated slicing somehow, so that 
you can write generic code that takes all kinds of slicing-types 
(and use introspection perhaps to choose how they are used).

Not so easy to get right, I guess... Hm.

> If the DIP said it wanted to introduce a type that enforces it 
> will always point to the resource that is managed, that would 
> be fine. It just can't overtake T[] to mean that. It's way way 
> too disruptive. I'd be fine with new syntax as well (like 
> T[new] or whatnot).

Ok, I understand.

Maybe a type that will share the binary interface of C++ span and 
string_view. They are supposed to be the ones to use in function 
C++ function signatures to increase interoperability between 
libraries etc.

Right now it is a bit difficult to say how span<> will be adopted 
in C++ libraries, but I would imagine that it might end up being 
used for matrices as well "span<span<T>>". So binary 
compatibility could make sense.

More information about the Digitalmars-d mailing list