>>> The issue is that if I want to include another framework, and that
>>> framework has also defined it (or more likely relies on another framework
>>> that defines it) then swift gets upset about the multiple definitions. I
>>> really want to rely on those libraries, but if it makes my own framework
>>> have a danger of conflicts with other libraries then it will stop adoption
>>> of my framework as a result.
>>
>> This hasn't stopped a number of others from relying on types they've
>> defined, like the Result type, for example.
>
> Things like Result can be differentiated by the module name in case of
> conflict. That isn’t possible with operators.
>
> Also, there are now two versions of AlamoFire which need to be kept in sync
> depending on which Result type they use.
There’s exactly one version of Alamofire. Anyone maintaining a fork
that uses another Result type does so on their own time without support from
the Alamofire project itself.
That said, this is a major pain in the ass. About once a year we get a
request from someone for us to use the antitypical Result type instead of our
own. We reject it because we don’t want dependencies in such a highly used
library. So users have to go through the trouble of either bridging between the
two types or using some fork. It’s further complicated by the fact that in
Alamofire 4 / Swift 3 we switched to Result<T> instead of Result<T, E>, since
we deal with generic Errors from the underlying URLSession APIs most of the
time. That makes the bridging that much more complicated. But manual
differentiation can be tricky to make work, there were some unexpected gotchas.
So, do the 500,000+ combined installs of Alamofire and Result qualify
this type for inclusion in the standard library yet?
Jon_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
