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
wrote:
> 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