Does this mean that all current code using Dispatch is broken? Why not just have a `Dispatch` module which would wrap the current C `LibDispatch` module (per SPM naming convention). This way, not only would existing code still work after simply changing `import Dispatch` to `import LibDispatch`, but the implementation of the new Dispatch module would be much simpler since it simply be a wrapper. Plenty of third party libraries do this already (provide a Swifty api built on top of the current c api's). I don't see any practical reason why Apple's Dispatch module should get this special treatment. I mentioned this on the mailing list but got mostly ignored...
On Thu, May 19, 2016 at 9:49 PM Chris Lattner via swift-evolution < [email protected]> wrote: > > > On May 19, 2016, at 9:02 PM, Patrick Smith <[email protected]> wrote: > > > > Great stuff! Truly is a massive improvement to an already venerable API. > > > > Was there any consideration to make this a new module ‘Dispatch’, and > drop all the Dispatch- prefixes? Or rather, what is the reason for keeping > the prefixes? (Group could become WorkGroup to lessen naming conflicts) > > We discussed it briefly, but Swift currently lacks a developed model for > submodules, and tackling it should only be done with a holistic design. > If/when we introduce them and adapt dispatch to use them, we believe that > we can do so without massive impact to users code (we can phase it in over > time). > > -Chris > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > -- Dan Appel
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
