Also, avoiding all interface breakage may restrict a developer's flexibility more than you imagine. Consider:
* Adding an optional argument to a function or an optional class template argument, which should be a non-breaking change for most everybody, can break user code.
* Adding an overload can break user code.
* Adding a new name to a namespace can break user code.
I"m sure I could do all of these things.
I'm not sure what you mean.
What I mean is that I could easily do all these things unintentionally
Generally I would consider it a bug.
In my code.
In your code or the user's? If yours, are you seriously willing to say you won't introduce any new functions or types into an existing namespace?
From time to time I would expect the library to be extended by adding new functions and perhaps new types into an existing namespace. It has never occurred to me to that this could break user code - but now that you mention it I suppose it could if users had added their own stuff to the archive namespace. However, I would probably consider this a user error in that it violates the intention of name spaces to avoid just this problem.
I concede that in such a case I mght want to make different kind of change - but it hasn't happend yet.
* Will you continue to support MSVC6 et al forever? :-)
LOL - now that is a very interesting new topic.
Not entirely new. If you drop support for MSVC6, you have made a breaking change for some users.
I would say I intend to support MSVC6 as long as it cost me nothing to do so.
So if it began to cost you something, you'd drop support even though it would be a breaking change for some users?
And of course, that would be OK. Even in this case I might want to leave around the old version. But, I guess that my pledge would have to extended to cover this case. On the other hand, the "pledge" is mostly a retorical device to make a point so I'd rather not turn it into the tax code. Robert Ramey