I think this is an excellent idea, particularly for typed languages. For a typed language package manager, you can run the following verifications:
- for a patch version, all exported (name, type) pairs of A.B.C are identical to those of A.B.(C-1)
- for a minor version, enforce first rule, but allow new types for new names.
I think the Elm package manager does this, based on other comments here in this thread.
Either way, that sort of automatic “exports” verification could be a base layer in a semver verification package manager, with integration tests layered on top.
There's a lot more to in than that in practice. For example, in a language with function overloading and implicit conversions, adding an overload may silently change the meaning of existing code.
Sometimes, this can get very gnarly. For example, C# has overloading, and it also has type inference for lambdas; and it tries to make these two work seamlessly. So, consider something like this:
This is perfectly legal - just a couple of overloads. Now, suppose we call it like so:
F(x => x.ToUpper());
There's no type for x here, so compiler has to infer it; but it also has two possible overloads to deal with. The way it goes about it is by considering both, and seeing if the lambda "makes sense" - i.e. if the body compiles, and its result type (accounting for possible implicit conversions) matches that specified in the function type being considered.
Now, when it tries Func<int, int>, it doesn't work, because if x is int, it doesn't have a method ToUpper, so the body of the lambda is ill-formed. On the other hand, given Func<string, string>, x is string, ToUpper() is well-formed, and returns a string, matching the function type. So that's the overload that gets chosen.
Now consider what happens if someone adds a method called ToUpper to int: now the code that was compiling before, and that was calling ToUpper on string, will suddenly fail because of ambiguity.
In more complicated scenarios (e.g. involving inheritance), it is even possible to have code that silently changes its meaning in such circumstances, e.g. when overloading methods across several classes in a hierarchy. It'd be rather convoluted code, but not out of the realm of possibility.
- for a patch version, all exported (name, type) pairs of A.B.C are identical to those of A.B.(C-1)
- for a minor version, enforce first rule, but allow new types for new names.
I think the Elm package manager does this, based on other comments here in this thread.
Either way, that sort of automatic “exports” verification could be a base layer in a semver verification package manager, with integration tests layered on top.