On Thu, Jan 18, 2024 at 09:03:25AM +0100, Olaf Klinke wrote:
The implementation of a set of patterns (or the underlying type) can change in a manner that changes complete <-> incomplete in either direction. Such changes are non-breaking, provided there was no "contract" (COMPLETE pragma) that the patterns are *intended* to be complete.
You are right: It is possible that the types of the bidirectional patterns do not change, but the completeness changes. In your example given I would argue the contract is broken, because the new patterns are for a different type Foo. Instead
A major (often primary) use case of pattern synonyms is with opaque types that hide their constructors, and expose only pattern synonyms as "smart constructors". The internal structure of such types can evolve without introducing API changes, with the pattern synonyms providing backwards-compatible behaviour. My point is that which patterns are expected to be complete is an API design choice, subject to API stability decisions, and not just a matter of deductive reasoning. One might, for example, have a pattern that in the initial API implementation always matches (it is some sort of property check, that can't yet fail), and later versions of the API may make it possible for the pattern to fail (justifying its initial introduction). -- Viktor.