Five Projects Selected for SAOC 2019

[Gregor Mückl]

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.