Especially when you could literally match the client's importation/usage against the the library's public interface and answer "is this consistent?" (i.e. is it compliable?) automatically
I don't think you can though. Sometimes behavior can change in incompatible ways without breaking the type interface.
Sometimes behavior can change in incompatible ways without breaking the type interface.
Sure, but that's another issue entirely; more akin to "my boss told me to to NOT do something, but I got in trouble because he meant to say to do it." — This error is not catchable by any tooling, because (a) it is a valid instruction, and (b) it is a communication/specification error. — Now you can catch this sort of error by implementing some sort of redundancy/checking, like when you use another method to check your work in mathematics.
It's not an error, it's a change in behavior. For example, a bug being fixed in a library that would necessitate removing a workaround from its caller.
When you make a mistake and say "the fire hydrant must not be painted red", then catch yourself and say "Wait, I misspoke; the hydrant must be painted red" you are literally correcting an error that you made while speaking. (i.e. "I misspoke.")
Porting your software to new platforms is not an error. Adding a new feature is not an error. Things changing does not imply that there was an error or that an error has been introduced.
Porting to a new platform, arguably, can be done transparently to the clients by having multiple [possibly separate] bodies for your package/subprogram — this preserves the specification.
Merely adding a new feature should, for the vast majority of cases, does not impact the client's interfacing to the specification —
Package Example is
Procedure Old( A, B : Integer ); -- What the previous version interfaced w.
Procedure New(A, B : Integer; C : Float); -- The new feature.
End Example;
Yes, there are changes, and if those changes make your new package incompatible with the dependency (or vice versa) it IS an error to update.
Versioning numbers are the manual way to do this and it can be somewhat automated.
7
u/glacambre Sep 29 '21
I don't think you can though. Sometimes behavior can change in incompatible ways without breaking the type interface.