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


(Chris Lattner) #1

Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0088-libdispatch-for-swift3.md

Hello Swift Community,

The review of "SE-0088: Modernize libdispatch for Swift 3 naming conventions" ran from May 10…17, 2016. The proposal is *accepted with revisions* for Swift 3.

The community and core team are both very positive about this massive improvement to the libdispatch APIs. Much of the discussion has centered around specific details in the proposal - for example the “.asynchronously” method on DispatchQueue. This great discussion leads to several requested revisions in the proposal:

- Rename the DispatchQueue.[a]synchronously methods to ".async” and ".sync”, to follow the term of art.
- Rename DispatchIO setHighWater, setLowWater --> setLimit(highWater:), setLimit(lowWater:)
- Rename setTargetQueue(queue:) and DispatchSource.setTimer
- Rename Semaphore, Group and WorkItem: .wait(timeout:) --> wait() and wait(withTimeout:)
- Expand source handler methods to take the same arguments as async()
- Expand DispatchQueue.after to take the same arguments as async() in addition to the when: argument

Thank you to Matt Wright proposing this, and for all of the implementation work that has gone into this so far!

-Chris Lattner
Review Manager


(Patrick Smith) #2

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)

···

On 20 May 2016, at 1:57 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0088-libdispatch-for-swift3.md

Hello Swift Community,

The review of "SE-0088: Modernize libdispatch for Swift 3 naming conventions" ran from May 10…17, 2016. The proposal is *accepted with revisions* for Swift 3.

The community and core team are both very positive about this massive improvement to the libdispatch APIs. Much of the discussion has centered around specific details in the proposal - for example the “.asynchronously” method on DispatchQueue. This great discussion leads to several requested revisions in the proposal:

- Rename the DispatchQueue.[a]synchronously methods to ".async” and ".sync”, to follow the term of art.
- Rename DispatchIO setHighWater, setLowWater --> setLimit(highWater:), setLimit(lowWater:)
- Rename setTargetQueue(queue:) and DispatchSource.setTimer
- Rename Semaphore, Group and WorkItem: .wait(timeout:) --> wait() and wait(withTimeout:)
- Expand source handler methods to take the same arguments as async()
- Expand DispatchQueue.after to take the same arguments as async() in addition to the when: argument

Thank you to Matt Wright proposing this, and for all of the implementation work that has gone into this so far!

-Chris Lattner
Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Chris Lattner) #3

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

···

On May 19, 2016, at 9:02 PM, Patrick Smith <pgwsmith@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)


(Chris Lattner) #4

Yep, I’ve asked Matt to do that.

-Chris

···

On May 19, 2016, at 9:07 PM, Jacob Bandes-Storch <jtbandes@gmail.com> wrote:

This is great!

What will setTargetQueue and setTimer become? It would be great if the proposal doc could be updated with the API that was accepted.


(Chris Lattner) #5

Are you asking about Swift 2.2 code?

Swift 2.2 code is generally completely incompatible with Swift 3 for a lot of other reasons (e.g. major changes to the standard library APIs). Swift 2.2 code should be run through a migrator, which is able to automatically handle changes like this.

-Chris

···

On May 19, 2016, at 9:53 PM, Dan Appel <dan.appel00@gmail.com> wrote:

Does this mean that all current code using Dispatch is broken?


(Chris Lattner) #6

>Swift 2.2 code should be run through a migrator, which is able to automatically handle changes like this.

Yes, but that's not really my point. Why do it this "magical" way?

Because it means that there is exactly one API: not a canonical API and a similar-but-different and less efficient wrapper. The approach taken here generalizes to other (similarly structured) C APIs as well.

As I mentioned before this isn’t about breaking code, so let me flip your question around: Why not do it?

-Chris

···

On May 19, 2016, at 10:02 PM, Dan Appel <dan.appel00@gmail.com> wrote:

It's already possible (and actually very easy) to wrap C modules such as libdispatch in a Swifty API (see Venice <https://github.com/VeniceX/Venice>, OpenSSL <https://github.com/Zewo/OpenSSL>, PostreSQL <https://github.com/Zewo/PostgreSQL> as examples). I know that LibDispatch is special to Swift and Apple, but I just don't see a reason to give it such a special treatment.

Dan

On Thu, May 19, 2016 at 9:56 PM Chris Lattner <clattner@apple.com <mailto:clattner@apple.com>> wrote:

> On May 19, 2016, at 9:53 PM, Dan Appel <dan.appel00@gmail.com <mailto:dan.appel00@gmail.com>> wrote:
>
> Does this mean that all current code using Dispatch is broken?

Are you asking about Swift 2.2 code?

Swift 2.2 code is generally completely incompatible with Swift 3 for a lot of other reasons (e.g. major changes to the standard library APIs). Swift 2.2 code should be run through a migrator, which is able to automatically handle changes like this.

-Chris
--
Dan Appel


(Chris Lattner) #7

>Because it means that there is exactly one API: not a canonical API and a similar-but-different and less efficient wrapper.

Fair enough.

>The approach taken here generalizes to other (similarly structured) C APIs as well.

I don't see any mention of this in the proposal. Is this related to the other C api translation proposal?

Yes, this is basically a “review libdispatch’s adoption of SE-0044 and other recent features” proposal.

>Why not do it?

Well, I want "equal opportunity" for all libraries.

I agree.

-Chris

···

On May 19, 2016, at 10:17 PM, Dan Appel <dan.appel00@gmail.com> wrote:


(Chris Lattner) #8

Well, I am in full support then. Thanks for being patient here!

No problem at all, thanks!

-Chris

···

On May 19, 2016, at 10:26 PM, Dan Appel <dan.appel00@gmail.com> wrote:

On Thu, May 19, 2016 at 10:23 PM Chris Lattner <clattner@apple.com <mailto:clattner@apple.com>> wrote:
On May 19, 2016, at 10:17 PM, Dan Appel <dan.appel00@gmail.com <mailto:dan.appel00@gmail.com>> wrote:
> >Because it means that there is exactly one API: not a canonical API and a similar-but-different and less efficient wrapper.
>
> Fair enough.
>
> >The approach taken here generalizes to other (similarly structured) C APIs as well.
>
> I don't see any mention of this in the proposal. Is this related to the other C api translation proposal?

Yes, this is basically a “review libdispatch’s adoption of SE-0044 and other recent features” proposal.

> >Why not do it?
>
> Well, I want "equal opportunity" for all libraries.

I agree.

-Chris

--
Dan Appel


(Jacob Bandes-Storch) #9

This is great!

What will setTargetQueue and setTimer become? It would be great if the
proposal doc could be updated with the API that was accepted.

···

On Thu, May 19, 2016 at 9:03 PM Patrick Smith via swift-evolution < swift-evolution@swift.org> 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)

> On 20 May 2016, at 1:57 PM, Chris Lattner via swift-evolution < > swift-evolution@swift.org> wrote:
>
> Proposal link:
https://github.com/apple/swift-evolution/blob/master/proposals/0088-libdispatch-for-swift3.md
>
> Hello Swift Community,
>
> The review of "SE-0088: Modernize libdispatch for Swift 3 naming
conventions" ran from May 10…17, 2016. The proposal is *accepted with
revisions* for Swift 3.
>
> The community and core team are both very positive about this massive
improvement to the libdispatch APIs. Much of the discussion has centered
around specific details in the proposal - for example the “.asynchronously”
method on DispatchQueue. This great discussion leads to several requested
revisions in the proposal:
>
> - Rename the DispatchQueue.[a]synchronously methods to ".async” and
".sync”, to follow the term of art.
> - Rename DispatchIO setHighWater, setLowWater --> setLimit(highWater:),
setLimit(lowWater:)
> - Rename setTargetQueue(queue:) and DispatchSource.setTimer
> - Rename Semaphore, Group and WorkItem: .wait(timeout:) --> wait() and
wait(withTimeout:)
> - Expand source handler methods to take the same arguments as async()
> - Expand DispatchQueue.after to take the same arguments as async() in
addition to the when: argument
>
> Thank you to Matt Wright proposing this, and for all of the
implementation work that has gone into this so far!
>
> -Chris Lattner
> Review Manager
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Dan Appel) #10

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

> On May 19, 2016, at 9:02 PM, Patrick Smith <pgwsmith@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Dan Appel


(Dan Appel) #11

Swift 2.2 code should be run through a migrator, which is able to

automatically handle changes like this.

Yes, but that's not really my point. Why do it this "magical" way? It's
already possible (and actually very easy) to wrap C modules such as
libdispatch in a Swifty API (see Venice <https://github.com/VeniceX/Venice>,
OpenSSL <https://github.com/Zewo/OpenSSL>, PostreSQL
<https://github.com/Zewo/PostgreSQL> as examples). I know that LibDispatch
is special to Swift and Apple, but I just don't see a reason to give it
such a special treatment.

Dan

···

On Thu, May 19, 2016 at 9:56 PM Chris Lattner <clattner@apple.com> wrote:

> On May 19, 2016, at 9:53 PM, Dan Appel <dan.appel00@gmail.com> wrote:
>
> Does this mean that all current code using Dispatch is broken?

Are you asking about Swift 2.2 code?

Swift 2.2 code is generally completely incompatible with Swift 3 for a lot
of other reasons (e.g. major changes to the standard library APIs). Swift
2.2 code should be run through a migrator, which is able to automatically
handle changes like this.

-Chris

--
Dan Appel


(Dan Appel) #12

Because it means that there is exactly one API: not a canonical API and a

similar-but-different and less efficient wrapper.

Fair enough.

The approach taken here generalizes to other (similarly structured) C APIs

as well.

I don't see any mention of this in the proposal. Is this related to the
other C api translation proposal?

Why not do it?

Well, I want "equal opportunity" for all libraries. I am a huge fan of the
structured concurrency scheme that Venice
<https://github.com/VeniceX/Venice> provides by wrapping libmill, and I
don't want it (or any other C libraries) to lag behind LibDispatch simply
because it is not Apple's own. If the changes in this proposal do affect
all c libraries, then obviously I am all for it. But the way I see it, and
please correct me if I am mistaken, giving LibDispatch special treatment
adds an extra crutch to other third party libraries which would otherwise
be on a level playing field.

Dan

···

On Thu, May 19, 2016 at 10:05 PM Chris Lattner <clattner@apple.com> wrote:

On May 19, 2016, at 10:02 PM, Dan Appel <dan.appel00@gmail.com> wrote:

>Swift 2.2 code should be run through a migrator, which is able to
automatically handle changes like this.

Yes, but that's not really my point. Why do it this "magical" way?

Because it means that there is exactly one API: not a canonical API and a
similar-but-different and less efficient wrapper. The approach taken here
generalizes to other (similarly structured) C APIs as well.

As I mentioned before this isn’t about breaking code, so let me flip your
question around: Why not do it?

-Chris

It's already possible (and actually very easy) to wrap C modules such as
libdispatch in a Swifty API (see Venice
<https://github.com/VeniceX/Venice>, OpenSSL
<https://github.com/Zewo/OpenSSL>, PostreSQL
<https://github.com/Zewo/PostgreSQL> as examples). I know that
LibDispatch is special to Swift and Apple, but I just don't see a reason to
give it such a special treatment.

Dan

On Thu, May 19, 2016 at 9:56 PM Chris Lattner <clattner@apple.com> wrote:

> On May 19, 2016, at 9:53 PM, Dan Appel <dan.appel00@gmail.com> wrote:
>
> Does this mean that all current code using Dispatch is broken?

Are you asking about Swift 2.2 code?

Swift 2.2 code is generally completely incompatible with Swift 3 for a
lot of other reasons (e.g. major changes to the standard library APIs).
Swift 2.2 code should be run through a migrator, which is able to
automatically handle changes like this.

-Chris

--
Dan Appel

--

Dan Appel


(Dan Appel) #13

Well, I am in full support then. Thanks for being patient here!

···

On Thu, May 19, 2016 at 10:23 PM Chris Lattner <clattner@apple.com> wrote:

On May 19, 2016, at 10:17 PM, Dan Appel <dan.appel00@gmail.com> wrote:
> >Because it means that there is exactly one API: not a canonical API and
a similar-but-different and less efficient wrapper.
>
> Fair enough.
>
> >The approach taken here generalizes to other (similarly structured) C
APIs as well.
>
> I don't see any mention of this in the proposal. Is this related to the
other C api translation proposal?

Yes, this is basically a “review libdispatch’s adoption of SE-0044 and
other recent features” proposal.

> >Why not do it?
>
> Well, I want "equal opportunity" for all libraries.

I agree.

-Chris

--

Dan Appel