On "A New Collections Framework for the Standard Library"

Jonathan M Davis via Digitalmars-d digitalmars-d at puremagic.com
Thu May 18 23:33:45 PDT 2017


On Friday, May 19, 2017 1:22:50 AM PDT Jack Stouffer via Digitalmars-d 
wrote:
> First off, how are you going to do something like a map over a
> immutable container then, as map uses the range primitives and
> not foreach? There's no reason in principal that that should
> cause an issue. But with that design popFront is mutating the
> underlying data, and therefore should not be allowed. But this
> works with the std.container design because popFront is mutating
> the range view which has no reason to be immutable.

Andrei was talking at dconf about this and said that we'd be adding a new
range primitive called tail, and we'd basically end up with car and cdr for
ranges. This makes sense for immutable ranges, and it's simple to wrap
existing input ranges to makes them work with such primitives, but I'm not
sure that it plays at all nicely once you start considering higher order
ranges - and it has the serious problem that it would require revamping all
range-based code to support it. That _might_ make sense for Phobos, since
it's the standard library, but I expect that its DOA pretty much everywhere
else (especially when it's for immutable containers which can be very useful
but are usually very niche), and even for Phobos, it's going to be a lot of
churn. Personally, I'm not convinced that immutable containers are worth
enough to merit such a change, but Andrei clearly thinks that they are.
Interesingly, he doesn't seem to think that it's worth solving the
tail-const issue with ranges, and without a solution for that, const and
ranges basically so not work together at all. And _that_ is a problem that
keeps coming up, whereas most folks don't seem to be clammering for
immutable containers.

Now, if you're willing to add a layer of indirection, then it's trivial to
make existing ranges over immutable containers work, because you can have a
mutable range refer to an immutable object, but that is either going to be
unsafe or require that the range be allocated on the heap - which is
presumably why Andrei didn't go with that solution, but I don't know.

But overall, it sounds like once again Andrei is getting very experimental
with what he's doing (or getting his mentee to do). So if it works out well,
we could end up with something pretty interesting and innovative, but it
also risks being a bit of a disaster, and since it's experimental, there's
really no way to know how it's going to go (even less so when all we know
about it is what was in the talk and whatever tidbits Andrei has discussed
in the newsgroup or at dconf). So, I guess that we'll have to wait and see -
particularly since we haven't even seen the actual API yet.

- Jonathan M Davis



More information about the Digitalmars-d mailing list