Containers
deadalnix
deadalnix at gmail.com
Tue Aug 31 17:21:02 UTC 2021
I want to start working on a container library. Interestingly
enough, I don't think we have what we need on that front.
I'll describe here what are the design I intend to go for, and
the rationales for it, but before, there is an unsolved problem
that I don't know how to work around that is somewhat of a
blocker. If one of you guys have an idea how to solve it, I'm
taking. If I'm being honest, this is probably the most important
problem that need to be solved for D right now. That problem is
turtling down type qualifiers.
For instance, if we have a Vector!T, then we want it to convert
to a Vector!(const T) and we want const(Vector!T) ==
const(Vector!(const T)), all of it implicitly. Same goes for
other qualifiers.
To put it bluntly, I have no idea how to achieve this. And I
don't think we'll have a good set of collection before this is
sorted out.
Now onto the design:
- Value types. It is very easy to turn a value into a reference
type, not so much the other way around. reference type also come
with a bag of edges cases, like the collection being null vs
empty, that cause confusion and problems in practice.
- COW. Value type collection can be very expensive to work with
if the eagerly copy everything. On the other hand, COW ensures
copies are cheap. There are also very common use case that are
well served by COW collections, for instance, when one wants
value types for collection that are infrequently changes - but
you don't know or can't prove that they won't.
- Small collection features. As every engineer, but no
mathematician will tell you, is that most numbers are small. It
is also true of collection sizes. In order to speed things up for
collection that are expected to be small, being able to specify
Vector!(T, 8) to reserve 8 slots for elements, in the base
collection, and only allocate on heap if the collection size
grows past this. LLVM has a collection library doing so and it is
the most useful thing in the world (see
https://www.youtube.com/watch?v=vElZc6zSIXM for more details).
- Not expose much of its internals. This like iterators being
raw pointers (or the result of using the in operator) for
instance, impose constraint on the internal that almost always
end up costing a ton of perf as new techniques are discovered
(recent exemples include open addressing with SSE probing for
instance). All of this needs to be wrapped.
I have a good idea how to solve all these problems. I have no
idea how to solve the type qualifier one. I need help.
More information about the Digitalmars-d
mailing list