container stuff

[Jonathan M Davis]

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.