On Monday, 26 August 2019 at 11:03:51 UTC, Jacob Carlborg wrote:
On 2019-08-26 05:55, Andrej Mitrovic wrote:
I'm guessing this means we might even be able to use multiple
versions of Phobos one day. However before we do that, we will
really need to fix the use of globals in Phobos.
I don't think that's necessary. All symbols will have the
version be part of the mangled name.
Hm... this approach has a few scenarios where I imagine that it
fails in weird ways:
- resources that can be initialized only once that are
encapsulated in a library: e.g. two versions of a logging library
that write to the same file and recreate the file during
initialization. On Windows, opening the same file for writing
again might fail. On Linux, it would replace the existing inode
entry for the file while both library instances continue to
happily write to their instance of the file.
- violating implicit expectations about relationships between
dependencies; for example, consider two libraries libFoo and
libBar working on data structures defined in a libCore. An
application uses all three of them and passes pointers to libCore
data structures to functions in libFoo and libBar. Recently,
libFoo and libCore have been updated and the libCore data
structures changed. The libBar update is not done yet. So if
libBar is built with its own private copy of the old libCore,
expectations about structure memory layouts are out of whack. If
something like that compiles and links, it's likely going to be
nearly impossible to debug.
The thing is that the resulting failure cases are likely
surprising, not obvious and therefore hard to debug. If you want
to do this, it should be optional and require explicit opt-in
from all dependencies in a chain. Libraries have to be designed
in very specific ways to make this work and these restrictions
would be new to the D ecosystem.
