RE: Predicate for true lists

[Drew Adams <drew.adams@oracle.com>]

>> 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.

I've already made my argument.  By your reasoning,
backward compatibility is a legalistic thing that
depends on doc, not behavior.  By mine, it's about
compatible behavior, not just how well the behavior
matches the doc.

By your reasoning, providing no doc at all means
there is no possibility of backward incompatibility!
 
If a faithful design spec is available then backward
compatibility can also be said to be about compatible
design changes (which is why I said "intended" behavior).

But a faithful design spec makes clear (explicitly or
implicitly/logically), the parts that are undefined
(bottom).  When a design change occurs that is not
compatible (same behavior models, or a subset),
backward incompatibility results.  Whether the change
is worth that incompatibility is a design decision.

And there is a difference between a faithful design spec
and doc.  See previous reply, about judgments whether
this or that behavior aspect should be documented.

Some backward incompatibility may be inconsequential for
some, or all, users - it depends.  There's a difference
between the existence of backward incompatibility and
whether or how much users might complain (or even notice).

For Emacs development, making design choices that change
behavior includes deciding when a backward-incompatible
change is worth it.  A design choice is not based just
on what the doc has said (does the doc give us enough
"leeway"?).  Doc is a user aid.  Doc is neither the
design nor the behavior that the design represents.

Mixing these things up as you've done, and tossing out
condescension about "elementary software engineering",
doesn't help.