Discussion about source-only design

[dukc]

So, the current plan is to have Phobos 3 to be source-only. That is, no object files of Phobos 3 will be precompiled, everything that is imported from it will be recompiled with the settings the client code uses.

I suspect this is done at least in part to avoid linking failures. Certain compiler flags, --preview=dip1000 at least, can change the ABI of symbol, which can result in linking failures between the client and the precompiled library object if different flags are used to compile it. This is precisely why I had to make std.file.dirEntries a template taking an autosetted bool parameter. It will certainly make development easier if we don't have to do workarounds like that.

I'd like to note, though, that this doesn't fully solve the issue. Consider an application, that used a dub library, let's call it DubLib, so that both use Phobos 3. DubLib is precompiled and has this function:

auto getDataFiles(Application app)
{
    string path;
    // ... figure out a value for path ...
    return path.dirEntries(SpanMode.breadth);
}

We're back at square one. DubLib has to be precompiled with the same DIP1000 setting as the client code or this will fail to link.

To be fair, this is the case even for Phobos 2. However, currently the function can at least be adapted:

import std.traits : isSafe;
enum dip1000Enabled = isSafe!((int x) => *&x);

auto getDataFiles(bool useDIP1000 = dip1000Enabled)(Application app)
{
    string path;
    // ... figure out a value for path ...
    return path.dirEntries!useDIP1000(SpanMode.Breadth);
}

You could try the same using Phobos 3 dirEntries:

import std.traits : isSafe;
enum dip1000Enabled = isSafe!((int x) => *&x);

auto getDataFiles(bool useDIP1000 = dip1000Enabled)(Application app)
{
    string path;
    // ... figure out a value for path ...
    return path.dirEntries(SpanMode.Breadth);
}

This at least ensures getDataFiles will be compiled with the flags the client uses, but dirEntries might already be instantiated somewhere else in DubLib and that instance might get reused, in which case there is going to be an ABI mismatch anyway. Therefore having dirEntries instances themselves separated by the compile-time flag is more robust. In addition, when there are compile-time flags in functions, it serves as a warning for the user that the ABI depends on the compiler flags.

Maybe this is a case of the perfect being the enemy of the good. Even if going source-only won't solve all the flag-related linking errors it is going to make them much more rare. But in any case, we need to aknowledge what tradeoff we're making, which is why I decided to bring this up.