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
