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