#CompileTimeDependencies and module resolution

[Sander Mak]

> The standard use case for the feature is for libraries with optional
> dependencies:

That is indeed the use case I was thinking of.

> The --add-modules flag is only relevant when using the command line to
> turn setup #1 into setup #2, something which should be rare.

Interesting, so what you're saying is if an application wants the optional behaviour of Lib through A, the application module itself (or any of its modules) has to declare a non-optional dependency in its descriptor on module A. Even though, technically, this application module doesn't have any direct relation at all with A. If you do that, the application can freely use types exported from A. Which is not always what you want (in most cases even, I'd say). For example, Lib would be a machine learning library that the application uses and A would be a super-fast matrix multiplication library (possibly with native code not available on all platforms, so it has to be optional). I won't ever use the matrix multiplication lib A directly in my application, but I want it to be used by Lib for increased performance. 

What I was expecting, is that the mere presence of A on the module path would cause it to be resolved when Lib is resolved, without needing a non-static requires or --add-modules. Conversely, if A isn't there, Lib would get resolved without A just as well. Obviously Lib needs to guard for this situation, as you said.

Alternatively, you can view optional dependency usage more like 'if the application already uses A, then Lib should also use A as well' in which case your suggested setup and the current implementation make total sense. This does make the example I described above a bit awkward, but I don't have any data on which use case is more prevalent.

Thanks for the insights!


Sander