Andrei Alexandrescu wrote: > It might not be weird if you want to write container-independent code.
Well, I've never needed to do that particular operation on _any_ container, so it does strike me as weird regardless. I've basically always been looking to remove a specific element or elements or to remove the element at a specific location. I don't ever recall being in a situation where it made any sense to remove an element without caring which one. But that's obviously not to say that no one else would find it useful. And std.container does not and obviously should not revolve around what I alone would find useful. As for container-independent code, there are certainly times when I've written code that was container-independent, but I don't think that it's something that I've done all that often. I agree that it can be quite useful and powerful to do so, but generally I've found that it breaks down because the various containers are too disparate both in function and performance. For instance, the STL makes it so that you at least _think_ that you can write container-independent code, but it's quite easy to run into instances where you really want to use a function that's specific to a container instead of the version in the algorithm library, or the functions are just different enough between container types that it doesn't work, or the operation that you're trying to do works fine with one container but would invalidate iterators on another, or... The list goes on. Effective STL certainly advises you to not really write container-independent code, generally-speaking, because it doesn't really work. The fact that the operations in std.container carry specific performance constraints will make it work much better I think. Also, D's ability to alter how a function is defined based on the attributes of a given container makes it much easier to write algorithms which are efficient for each container type without having to worry about calling member functions in some cases and non-member functions in others or anything like that. So, I think that std.container really looks like it could lead me to write good, container-independent code. However, I don't have much experience with writing container-independent code because it doesn't work very well in C++, and it can be quite detrimental to performance in other languages like Java because the performance characteristics of different containers vary so much. In any case, std.container looks pretty good thus far. I just found removeElement() weird because I coudn't see why anyone would ever need such a function. - Jonathan M Davis P.S. I have to agree that removeAny() and removeAnyStable() are better names. It's certainly less confusing as to what they're doing.