"Code and Contract Evolution" lacks discussion of implicit postconditions

[katzdm]

The Code and Contract Evolution section lacks a discussion of "implicit postconditions": observable effects of a function (whether side-effects or otherwise) that a caller empirically discovers. In practice, the tendency of callers to depend on such behaviors significantly impairs our ability to evolve how a function or type is implemented (hence, Hyrum's Law aka "The Law of Implicit Interfaces"). A classic example is a hash container whose callers accidentally depend on the iteration order of its elements, which effectively freezes the implementation of the container (given enough misbehaving users).

The perspective taken by the book might argue that clients depending on a postcondition not part of the contract are not "correct clients". In practice, and especially at scale, it seems inevitable that many clients will not be correct. It therefore seems worthwhile to discuss code and contract evolution in the presence of incorrect clients who lack awareness of their dependence on unpublished postconditions.

One documented means of fighting this tendency is to purposefully introduce nondeterminism into observable effects that are not governed by the contract. In the case of the hash container, for instance, production implementations have been deployed which inject nondeterminism (e.g., timestamp, git commit hash, etc) into the iteration order to guard against callers depending on it. It's not feasible to deploy such tricks for all conceivable postconditions, but I think the valuable lesson is: The observable effects of an interface should hew as closely to the contractually guaranteed postconditions as possible.

In the context of evolving code - especially pertaining to "evolving implementations" and "strengthening postconditions" - this feels like an important topic worth covering.

[dabrahams]

Thanks for the feedback. I agree that some coverage is warranted.

Hyrum's Law doesn't say what you are reading into it, at least not the text of the law itself. The law itself is merely an observation about the dynamics of software. It is not, in fact, “The Law of Implicit Interfaces,” and his page doesn't say it is.

The idea that the Law freezes the implementation depends on the assumption that there is an imperative that incorrect clients continue to function exactly the same way forever, without modification of client code, but with an update to use your new implementation. Most software does not exist with such an imperative, and adopting it unnecessarily has a high engineering cost. To begin with, most clients are not obliged to switch to updated versions of a component. In Google's monorepo development process, where Hyrum's law was first observed, that isn't the case—there is an essentially intractable amount of code with no internal interface boundaries or versioning. Hyrum himself notes that the “law of implicit interfaces” is just the result of taking his Law “to the logical extreme.” To the extent that his page implies all observable effects must be treated as part of the contract, I disagree with it. IMO that view is harmful, and I might have a word with Hyrum about adjusting the language to clarify.

The randomized hash seed thing is a good example; Swift's hash containers use that method. Swift adopted it for security reasons after having not used it for many years. We were aware of Hyrum's law. Some client code stopped working. Clients were able to choose when to update to the latest Swift and were able to test the change according. The world didn't end. That said, it wasn't done lightly: users were made aware of this potential issue. But also this change is more likely to affect users than others. When Swift made the default sorting algorithm stable, no such notice was given, and it didn't cause problems that we ever heard about. The problem is that I don't know how to characterize which things require that kind of care.

As phrased, your lesson, “the observable effects of an interface should hew as closely to the contractually guaranteed postconditions as possible,” constrains the effects, not the contract, so it says the opposite thing. I have no argument with that, but the idea that the (observable) effects must satisfy postconditions is already covered thoroughly by the text.