[swift-evolution] Beyond Typewriter-Styled Code in Swift, Adoption of Symbols

[Jon Shier]

>>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170901/130c738a/attachment.html>