[swift-evolution] [Accepted with Revision] SE-0088: Modernize libdispatch for Swift 3 naming conventions

[Dan Appel]

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 <
swift-evolution at swift.org> wrote:

>
> > On May 19, 2016, at 9:02 PM, Patrick Smith <pgwsmith at gmail.com> 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
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-- 
Dan Appel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160520/65993c91/attachment.html>