container stuff

[bearophile]

Andrei Alexandrescu:

>I feel this design is pretty close to what I really wanted.<

Good :-)

How is opApply playing in the design of the containers? Can opSlice return a struct that defines opApply?


> There are a bunch of "soft" primitives. Those are meant to put a stop to 
> the iterator invalidation problems experienced in the STL.

I can suggest another thing, that doesn't replace this idea, but can make the nonsoft primitives a little safer when the program is compiled in nonrelease mode: http://d.puremagic.com/issues/show_bug.cgi?id=4179


>any container must be a reference type, whether implemented as a class or struct.<

This probably makes their usage simpler, so this can be the right decision. But then you can't define something like a TinyHashSet or a StaticBitSet that are better allocated on the stack... (a StaticBitSet is a struct template I have defined, at compile time you give it its length and it gets allocated on the stack, and represents a set of integers in an intgerval, or something similar).

Why is length O(log(n))? If a linked list has no length field, to compute its length it has to scan all of it.

make(): this has just killed the new :-)

Among the standard primitives is it useful to have something to ask the actual computational complexity of a specific operation of a specific container? There are some ways to implement this, the simplest is to define enum with the most common complexities, and then a collection can contain an enum (const) value for each operation, something like:
enum lengthComplexity = CompComplexity.linear;
I don't know if this can be useful (to choose collections, to infer code complexity, etc).

Bye,
bearophile