Data evolution with set-theoretic types
Recently I have been working on projects that integrate Elixir with native code in C and Rust. One of the Rust libraries defines the following struct (with fields removed for simplicity):
It turns out the structure above does not follow the C specification, which says the name may be null. Unfortunately, the C library I used was producing data with the name set to null, making it impossible to interoperate with the Rust one.
I was the one unluck one to find this out. Even though the library is well used within the Rust ecosystem, by several projects throughout the years, nobody ran into this before. The ideal solution is to change the type of the struct field, perhaps by wrapping the name into an Option type:
However, doing so would effectively break ALL existing users of the library. Who am I to propose such a breaking change to a library, based on a scenario that apparently no one else ran into after a few years? Such change would effectively split the library’ ecosystem in two.
Alternatively, we could convert nulls into empty strings, keeping the current type definition and compatibility, but still not following the spec. This was the option taken for this particular case.
