Complexity nomenclature

[Jonathan M Davis via Digitalmars-d]

On Friday, 4 December 2015 at 14:51:40 UTC, CraigDillabaugh wrote:
> My personal preference would be not to have the complexity in 
> the names, as I prefer shorter/concise names. Typically when I 
> am writing code using containers of any sort I will check the 
> documentation to determine what the cost of the operations I 
> need is and base my choice off of that. I would think (hope) 
> most others do this too.  However, I don't have a strong 
> objection to the what is being proposed.

std.container puts linear and/or stable in some of its names and 
then creates an alias to whichever one makes sense as the default 
where the alias doesn't have linear or stable in the name. e.g. 
linearRemove becomes remove via an alias.

But actually using something like stableLinearRemove in code (or 
stable.linear.remove) becomes hideous _very_ quickly. No one is 
going to like it, and it really only benefits generic code, which 
most container code really isn't (and given how different 
containers tend to be in the complexity of their operations, I 
question that it even makes sense to use containers generically 
in many cases if you actually care about efficiency). Usually the 
genericity is achieved via iterators or ranges, not via the code 
that actually operates on the container.

So, while I applaud Andrei's attempt to make it so that 
containers can be used generically where appropriate (and having 
a consistent API across containers is a big win even if they're 
never used generically), I do fear that attempts to put the 
complexity and stability of the functions into the API are going 
to make it so unwieldy that it's useless (or at least, very 
un-user-friendly). Obviously, we'll have to wait and see what he 
comes up with, but what almost everyone is going to want is 
remove and insert and the like, not stable.linear.insert or 
stableLinearInsert or any variant on that.

- Jonathan M Davis