[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Predicate for true lists

From: Paul Eggert
Subject: Re: Predicate for true lists
Date: Sun, 8 Jul 2018 09:00:04 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]