Re: Predicate for true lists

[Paul Eggert]

Drew Adams wrote:
> I specifically distinguished between design (intended
> behavior) and implementation (actual behavior, with bugs).

That's a nonstandard distinction. The more normal distinction is that design 
covers the strategy for implementing what users want or need, and implementation 
covers the details of what the code actually does. For now, let's simplify the 
discussion by stipulating that this code is bug-free, as bugs are a red herring 
here (nobody is asserting that 'length' has a bug).

> My point was that not mentioning error-handling behavior
> does _not_ make a future change less backward-incompatible.

Your point was incorrect. If a function does not explicitly document its 
behavior when given a value of the wrong type, there is greater leeway for 
extension in the future. Conversely, if a function's documentation goes out of 
its way to say explicitly that it signals an error for a wrong type, even though 
this is not common practice in function documentation, users will not 
unreasonably conclude that there's something special about this function, and 
that it is not likely to be extended in the future in the same way that an 
ordinary function would be extended.

> It's a mistake to think or pretend that you're not breaking
> backward compatibility just because the behavior you change
> was never documented.

No, it's not a mistake at all. Relying on undocumented behavior is more likely 
to lead to future bugs than not relying on undocumented behavior, and users know 
(or should know) this when they write their code. So, changing undocumented 
behavior is less likely to break user code than changing documented behavior is. 
This is all elementary software engineering. We should not base our work on the 
theory that any code change that alters machine instructions is "breaking 
compatibility" (the absolutist position), because that is too strict a notion of 
"compatibility" to be of much practical use.