Hyrum's Law

One approach to guard against Hyrum’s Law is GREASE (aka “Generate Random Extensions And Sustain Extensibility” used in the TLS 1.3 protocol) i.e. behavior randomization to avoid inadvertent dependencies on unspecified behavior: https://textslashplain.com/2020/05/18/a-bit-of-grease-keeps-... What are other approaches?

This is an argument for maintainers to routinely change any unspecified behavior that doesn't cost (much) more to do it the new way, on each release. In a hash, tweak the hash function. Downstream dependents breaking because they depend on undocumented behavior is their fault, not your fault. The sooner they break, the less it costs.

There's a corollary: Even if you explicitly deny a guarantee of a certain behavior in your contract, if you usually deliver that behavior, most of your customers will depend on it. Some examples: If you make a queueing system, it's impossible to guarantee anything other than delivery "at most once" (some loss occurs), or "at least once" (some duplication occurs), but if you usually provide "exactly once" in practice, most of your customers will depend on this. If you provide…

I see Hyrum's Law as the highlighting a problem with the robustness principle. You start with: We followed the robustness principle, which is be conservative in what you do and be liberal in what you accept from others But then, the 'things you accept' become part of your api: The problem with the robustness principle is a flaw can become entrenched as the defacto standard. Any implementation of a protocol is required to replicate the apparent behavior. This is both…