> The review of "SE-0075: Adding a Build Configuration Import Test" begins now
> and runs through May 16. The proposal is available here:
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0075-import-test.md
>
> * What is your evaluation of the proposal?
+1, I think it's a welcome change that improves modularity between libraries.
> * Is the problem being addressed significant enough to warrant a change
> to Swift?
Yes.
There's another real problem that this feature solves which I couldn't see
mentioned in the proposal: adding protocol conformances to optional
dependencies. Suppose a library named Frobnication defined a protocol
`Frobnicatable`, with some known conformances:
// module Frobnication
public protocol Frobnicatable {
mutating func frobnicate()
}
extension String : Frobnicatable { ... }
extension Frob : Frobnicatable { ... }
Now, suppose something in a 3rd party library called Knobs was also clearly
`Frobnicatable` but `canImport` didn't exist. The community would have to pick
from the following poorly scaling alternatives:
#1) Either Frobnication would require and import Knobs as its dependency and
add the conformances,
#2) or vice versa, Knobs would pull Frobnication as its dependency,
#3) or everybody using both libraries would need to define the conformances
theirselves,
#4) or someone would need to maintain a "KnobsFrobnication" library for the
sole purpose of defining the said protocol conformances.
* * *
With `canImport`, on the other hand, we get two good options:
#5) Either Frobnication checks `#if canImport(Knobs)` and conditionally adds
the conformances,
#6) or Knobs checks if it `canImport(Frobnication)` and conditionally adds the
conformances to any suitable types it defines (which is what any new libraries
that the author of Frobnication wasn't aware of could do in the future).
* * *
But there remains one issue that there's no clear path for moving conformance
definitions from one library into the other one day. This proposal could be
improved by allowing to check for library versions too! If similarly to `#if
swift(>=2.2)`, we could check `#if canImport(Knobs >= @2.10.0)`, then the
authors of Knobs and Frobnication could organise an orchestrated move of
conformance definitions from one library into another. Before the move, Knobs
2.9.x would have defined:
// module Knobs 2.9.x
#if canImport(Frobnication)
import Frobnication
extension Knob : Frobnicatable { ... }
#endif
Preparing for the move, a new version of Frobnication could introduce the
conformance thusly:
// module Frobnication 1.7.3
#if canImport(Knobs >= @2.10.0) // *) see note below
import Knobs
extension Knob : Frobnicatable { ... }
#endif
Then, Knobs could gracefully sunset its conformance definitions beginning from
the 2.10.0 release:
// module Knobs 2.10.0
#if canImport(Frobnication < @1.7.3) // <- Only added version constraint
here.
import Frobnication
extension Knob : Frobnicatable { ... }
#endif
*) I'm not sold to any specific syntax, but we could e.g. use the `@` prefix to
distinguish version number literals like `@1`, `@0.10` and `@0.10.0` from
similar but differently behaving numeric literals.
In any case, even with just `canImport(module)`, we can do a lot better than
currently.
> * Does this proposal fit well with the feel and direction of Swift?
Yes.
> * If you have used other languages or libraries with a similar feature,
> how do you feel that this proposal compares to those?
Yes, like mentioned in the proposal, it's very similar to the
`__has_import(<path/to/import.h>)` macro in Clang. I'm not fully familiar with
the design space in Haskell, but it seems to me instead of using something
similar to `canImport` Haskellers tend to favour the approach I listed above as
alternative #4 (e.g. https://github.com/lens/lens-aeson/
<https://github.com/lens/lens-aeson/> brings the lens and aeson libraries
together).
> * How much effort did you put into your review? A glance, a quick
> reading, or an in-depth study?
Quick reading.
— Pyry
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
