I have a question related to design, implementation of programming languages. I hope it fits here and apologize if it doesn't.
All or most programming languages version modules (aka packages, libraries, crates). All the entities in a module (types, functions, variables and other information) share the same version with the module. However usually only some parts of a module change between a version and the next.
When two different modules use different versions of the same third module, this creates an incompatibility.
Some programming languages (for instance C and C++) ignore the problem altogether. They don't care about the version but only about the name and signature of entities. They accept programs that may crash or misbehave when executed, if different pieces of such programs expected different versions of a same entity that changed.
Other programming languages (for instance Rust or Node.js) trait different versions of the same entity as two completely different entities. This avoid crashes, but introduces unnecessary incompatibilities between entities that did not change.
This can be a big problem for modules that define many different entities and that lots of other modules depend on, for instance the standard library of a programming language. Most programming languages use special tricks for their standard libraries: for instance they tie the standard library's version to the compiler version and require to recompile everything when the compiler version changes.
A better solution to this problem could be versioning every entity independently instead of whole modules. The GNU implementation of the standard library of C and C++ do this. I have seen some Rust crates do this too by importing their previous version and re-exposing all the symbols that didn't change. But these processes are very tedious and easy to get wrong, hence very few pieces of software adopt similar practices.
Do we know of any good way to version entities in a fine-grained way?
Has there been any research on this problem?
A practical example
If the problem I described isn't clear, let me explain it with a practical example.
A module "time 1.0.0" defines loads of entities related to time. Among many others, it defines these two types:
type UnixTime = uint32_t; # seconds from 1970 Jan 1 type UnixTimeNS = uint32_t; # nanoseconds from 1970 Jan 1
After "time 1.0.0" is out, we realize that
UnixTimeNS is too small: it needs to be an
uint64_t. We change that type and release "time 2.0.0" since we did an incompatible API change. Nothing else changed in the whole "time" module besides that
Two other modules "logger" and "totp" depend on "time". The former was developed on "time 1.0.0", while the latter uses "time 2.0.0". They both only use
time::UnixTime and nothing else. This type did not change between the two version. But the compiler can't know that and treats
time_2.0.0::UnixTime as different, incompatible types. It's now very hard to use both "logger" and "totp".
Imagine if they make a similar change to the standard library of any existing language: it could result in a tremendous split between new and existing modules, something as catastrophic as the switch from Python 2 to Python 3. All for a very minor change that affects 0.1% of the existing code.
I developed a rust crate (https://github.com/BlueNebulaDev/rust-version-test) and a Node.js package (https://github.com/BlueNebulaDev/node-version-test/) to show this problem in action. The names used in these projects differ from the ones in the example described here, but the meaning is the same.