Re: [swift-evolution] [Review] SE-0088: Modernize libdispatch for Swift 3 naming conventions

Hi, I’m a +1 on the proposal, I think it’s a no brainer, but I do have one question... What is the reasoning behind repeating the module name in the type name? e.g we have `Dispatch.DispatchQueue`. Why not `Dispatch.Queue`? It seems a bit pointless for the Swift team to go to all that effort

Re: [swift-evolution] [Review] SE-0088: Modernize libdispatch for Swift 3 naming conventions

> On May 13, 2016, at 9:29 AM, plx via swift-evolution > wrote: > > >> * What is your evaluation of the proposal? > > +1 conceptually, some quibbles. > > I agree with a few others that `synchronously` and `asynchronously` aren’t > ideal;

Re: [swift-evolution] [Review] SE-0088: Modernize libdispatch for Swift 3 naming conventions

> On May 13, 2016, at 12:24 PM, Jacob Bandes-Storch wrote: > > This looks great. Thanks for revising. I'm now a +1 on this. > > A couple more minor suggestions: > > - Consider renaming setTimer(...) to resetTimer() or just reset(), or > something similar? setTimer

Re: [swift-evolution] [Review] SE-0088: Modernize libdispatch for Swift 3 naming conventions

> On May 13, 2016, at 12:29 PM, Xiaodi Wu wrote: > > More nits: > > setHighWater(highWater:) and its ilk should should probably be > setHighWater(_:) and so on (I include among these setInterval(interval:), > setTargetQueue(queue:), etc.) I suspect setHighWater and

Re: [swift-evolution] [Review] SE-0088: Modernize libdispatch for Swift 3 naming conventions

More nits: setHighWater(highWater:) and its ilk should should probably be setHighWater(_:) and so on (I include among these setInterval(interval:), setTargetQueue(queue:), etc.) Similarly, in terms of conforming to Swift guidelines, I notice many instances where labels repeat the parameter type,

Re: [swift-evolution] [Review] SE-0088: Modernize libdispatch for Swift 3 naming conventions

[Apologies for the weird threading, I missed the original email to the list so I can’t reply to it directly] I just wanted to let the list know that I updated proposal SE-0088 to fix the typos and include a more complete listing of the Dispatch module after the transformations in the proposal

Re: [swift-evolution] [Review] SE-0088: Modernize libdispatch for Swift 3 naming conventions

> * What is your evaluation of the proposal? +1 conceptually, some quibbles. I agree with a few others that `synchronously` and `asynchronously` aren’t ideal; `dispatchSynchronously` or `dispatchSync` (or `performSync` or `performSynchronously`) all seem more-appropriate. I understand

Re: [swift-evolution] [Review] SE-0088: Modernize libdispatch for Swift 3 naming conventions

> On May 12, 2016, at 22:29, Zach Waldowski via swift-evolution > > wrote: > > dispatch_get_context, dispatch_set_context are not around simply in the > absence of blocks. They're just as useful as the queue-specific data APIs as >

Re: [swift-evolution] [Review] SE-0088: Modernize libdispatch for Swift 3 naming conventions

dispatch_get_context, dispatch_set_context are not around simply in the absence of blocks. They're just as useful as the queue-specific data APIs as they have thread-specific storage. Zach Waldowski z...@waldowski.me On Thu, May 12, 2016, at 08:50 PM, Pierre Habouzit via swift-evolution

Re: [swift-evolution] [Review] SE-0088: Modernize libdispatch for Swift 3 naming conventions

+1 to naming like this. dispatch() and dispatchSynchronously() if needed to please thy naming gods. > On 13 May 2016, at 4:16 AM, Thorsten Seitz via swift-evolution > wrote: > > dispatch() and dispatchSync() would be my preference as asynchronous dispatch > is the

Re: [swift-evolution] [Review] SE-0088: Modernize libdispatch for Swift 3 naming conventions

> On May 12, 2016, at 10:49 AM, Jose Cheyo Jimenez via swift-evolution > wrote: > > >> On May 11, 2016, at 7:09 AM, Matt Wright via swift-evolution >> > wrote: >> >>> >>> On May 10, 2016, at 11:52 PM,

Re: [swift-evolution] [Review] SE-0088: Modernize libdispatch for Swift 3 naming conventions

> On 12 May 2016, at 19:03, Matt Wright wrote: > > Are you talking about ambiguity at a compiler level, or in human-reading? I meant ambiguous for people familiar with libdispatch.

Re: [swift-evolution] [Review] SE-0088: Modernize libdispatch for Swift 3 naming conventions

This would defeat @noescape and any generic return type we might want to add to dispatchSync. On Thu, May 12, 2016 at 11:52 AM Hooman Mehr via swift-evolution < swift-evolution@swift.org> wrote: > > Exactly: I also consider synchronous dispatch a special case not worthy of > sacrificing a better

Re: [swift-evolution] [Review] SE-0088: Modernize libdispatch for Swift 3 naming conventions

Exactly: I also consider synchronous dispatch a special case not worthy of sacrificing a better name (`dispatch`) for it. I prefer to have a single `dispatch` as the main function name. Here is my proposed modified signature based on the proposal

Re: [swift-evolution] [Review] SE-0088: Modernize libdispatch for Swift 3 naming conventions

dispatch() and dispatchSync() would be my preference as asynchronous dispatch is the point of GCD and synchronous dispatch is a special case and therefore I think the visual asymmetry is an advantage. -Thorsten > Am 12.05.2016 um 20:10 schrieb James Dempsey via swift-evolution >

Re: [swift-evolution] [Review] SE-0088: Modernize libdispatch for Swift 3 naming conventions

> On May 11, 2016, at 8:02 PM, Ricardo Parada wrote: > > > > For synchronously and asynchronously how about the adverbs before the verb: > > syncDispatch() > asyncDispatch() I think with the abbreviation ‘sync’ it’s very easy to read ‘sync’ as a verb and dispatch as a

Re: [swift-evolution] [Review] SE-0088: Modernize libdispatch for Swift 3 naming conventions

> On May 12, 2016, at 7:00 AM, Ben Rimmington via swift-evolution > wrote: > > 0088-libdispatch-for-swift3.md> > > ## Type Names > > I was going to suggest unprefixed type names, but having to

Re: [swift-evolution] [Review] SE-0088: Modernize libdispatch for Swift 3 naming conventions

> On May 11, 2016, at 7:09 AM, Matt Wright via swift-evolution > wrote: > >> >> On May 10, 2016, at 11:52 PM, Jacob Bandes-Storch via swift-evolution >> wrote: >> >> >>* What is your evaluation of the proposal? >> >> I'm

Re: [swift-evolution] [Review] SE-0088: Modernize libdispatch for Swift 3 naming conventions

Apologies all, my iPad and I are not getting on today ! > On 12 May 2016, at 16:33, Andrew Brown via swift-evolution > wrote: > > > On First, this is a huge breaking change, and it doesn’t really have to be > one. The current SPM convention is to prefix C libraries

Re: [swift-evolution] [Review] SE-0088: Modernize libdispatch for Swift 3 naming conventions

> On First, this is a huge breaking change, and it doesn’t really have to be > one. The current SPM convention is to prefix C libraries with Lib. Following > this convention, Dispatch (which is the C version) would be renamed to > LibDispatch, and this new wrapper library would be called just

Re: [swift-evolution] [Review] SE-0088: Modernize libdispatch for Swift 3 naming conventions

## Type Names I was going to suggest unprefixed type names, but having to qualify both `Dispatch.Data` and `Foundation.Data` would be an issue. If libdispatch had originally been part of Foundation,

Re: [swift-evolution] [Review] SE-0088: Modernize libdispatch for Swift 3 naming conventions

Hello, Does the proposal fixes the errors introduced by the latest May 9 snapshot ? Since IUO are abolished (https://github.com/apple/swift-evolution/blob/master/proposals/0054-abolish-iuo.md) and pointer nullability is expressed using Optional

Re: [swift-evolution] [Review] SE-0088: Modernize libdispatch for Swift 3 naming conventions

+1 I’d also vote for dispatchAsync and dispatchSync. For reference, c# is also a language with fairly verbose conventions like Swift and it has adopted the Async convention for their “async” methods. > On 11 May 2016, at 20:08, Darren Mo via swift-evolution > wrote:

Re: [swift-evolution] [Review] SE-0088: Modernize libdispatch for Swift 3 naming conventions

Great, this is the libdispatch API that I’ve been dreaming about! I think it meshes well with the rest of Swift. I am concerned about one thing though: the naming of the DispatchGroup methods synchronously/asynchronously. They are hard to type correctly and ugly to look at. sync/async are

Re: [swift-evolution] [Review] SE-0088: Modernize libdispatch for Swift 3 naming conventions

> * What is your evaluation of the proposal? I like it; with the fixes already mentioned by Matt, I have some extra comments and questions: - It would be nicer to use the Dispatch namespace, rather than prefix everything. - It seems unfortunate to have 11 DispatchSourceSUBTYPE protocols at top

Re: [swift-evolution] [Review] SE-0088: Modernize libdispatch for Swift 3 naming conventions

I don't recall seeing this proposal being pitched, and will also include feedback of that stripe. Other responses inline. On Wed, May 11, 2016, at 12:39 AM, Chris Lattner via swift-evolution wrote: > * What is your evaluation of the proposal? Strong +1 in concept. I'm thrilled that this

Re: [swift-evolution] [Review] SE-0088: Modernize libdispatch for Swift 3 naming conventions

Sorry, I realized after seeing Darren's message that I made a mistake. The abbreviation doesn't end with 'h'. It should be: dispatchAsync() dispatchSync() > On May 11, 2016, at 10:10 AM, Cole Campbell via swift-evolution > wrote: > >> My main piece of feedback is

Re: [swift-evolution] [Review] SE-0088: Modernize libdispatch for Swift 3 naming conventions

1. What is your evaluation of the proposal? +1 on the proposal’s objective - the swiftification of libdispatch is greatly appreciated. But I have reservation in the particulars of the proposal which are not in line with the API Design Guidelines. For example, the `getSpecific(_:)` instance

Re: [swift-evolution] [review] SE-0088: Modernize libdispatch for Swift 3 naming conventions

Great, this is the libdispatch API that I’ve been dreaming about! I think it meshes well with the rest of Swift. I am concerned about one thing though: the naming of the DispatchGroup methods synchronously/asynchronously. 1. They are hard to type correctly and ugly to look at. 2. sync/async

Re: [swift-evolution] [Review] SE-0088: Modernize libdispatch for Swift 3 naming conventions

I don’t know if this is a problem per-say, but very likely the API would often be used in code looking more like this: DispatchQueue.main.dispatchAsynch { // stuff } And maybe this is just me, but the double occurrence of the word “dispatch” in there rubs me the wrong way. :P This is

Re: [swift-evolution] [Review] SE-0088: Modernize libdispatch for Swift 3 naming conventions

> My main piece of feedback is that the method names synchronously() and > asynchronously() don’t conform to Swift 3 naming conventions for functions > and methods: I agree. > dispatchAsynch() > dispatchSynch() I prefer something like this. It feels more Swifty. As it is, they aren't any

Re: [swift-evolution] [Review] SE-0088: Modernize libdispatch for Swift 3 naming conventions

You could use dispatch(), and name the synchronous method something else? synchronize() or its shortened form sync(), which is a real word, or maybe wait(). (However, there was a beauty in the yin-yang of async/sync in the original API. I would call them terms of art, like map, filter, reduce,

Re: [swift-evolution] [Review] SE-0088: Modernize libdispatch for Swift 3 naming conventions

Jacob Bandes-Storch suggested: synchronously(execute work: …) So maybe that will conform to the API naming guideline? Or would the verb have to be in the base name of the func? Or perhaps: synchronously(dispatch work: …) asynchronously(dispatch work: …) > On May 11, 2016, at 9:32 AM,

Re: [swift-evolution] [Review] SE-0088: Modernize libdispatch for Swift 3 naming conventions

> On May 10, 2016, at 11:52 PM, Jacob Bandes-Storch via swift-evolution > wrote: > > > * What is your evaluation of the proposal? > > I'm generally in favor of a modernized API overlay like this (and I've > written something like it myself, albeit much

Re: [swift-evolution] [Review] SE-0088: Modernize libdispatch for Swift 3 naming conventions

I like the idea. I didn't see these function but I am not sure if they are part of that library. dispatch_queue_create("uniqueName", DISPATCH_QUEUE_CONCURRENT) dispatch_apply(someInt, queue){ > On May 10, 2016, at 9:39 PM, Chris Lattner via swift-evolution >

Re: [swift-evolution] [Review] SE-0088: Modernize libdispatch for Swift 3 naming conventions

My main piece of feedback is that the method names synchronously() and asynchronously() don’t conform to Swift 3 naming conventions for functions and methods: "Name functions and methods according to their side-effects • Those without side-effects should read as noun phrases, e.g.

Re: [swift-evolution] [Review] SE-0088: Modernize libdispatch for Swift 3 naming conventions

Hey Jacob, I agree with you that there are some unanswered questions and areas we would need some more polish on, but libdispatch was a bit unwieldy in Objective-C already and when used as is in Swift code it looks to be even less user friendly and not because it has to, but because of a lack

Re: [swift-evolution] [Review] SE-0088: Modernize libdispatch for Swift 3 naming conventions

* What is your evaluation of the proposal? I'm generally in favor of a modernized API overlay like this (and I've written something like it myself, albeit much simpler), but I'm hoping this proposal can go through another round or

Re: [swift-evolution] [Review] SE-0088: Modernize libdispatch for Swift 3 naming conventions

Excellent, thanks for answering my questions! If the classes should/can not be subclassed, they should probably be marked as 'final' in order to make this clear to consumers, regardless of performance or correctness implications. Austin On Tue, May 10, 2016 at 11:12 PM, Matt Wright

Re: [swift-evolution] [Review] SE-0088: Modernize libdispatch for Swift 3 naming conventions

> On May 10, 2016, at 10:22 PM, Austin Zheng via swift-evolution > wrote: > > I think this is a great idea and a great proposal. GCD is already a powerful, > elegant tool available to Swift users, and this makes it feel even more > Swift-like. > >

Re: [swift-evolution] [Review] SE-0088: Modernize libdispatch for Swift 3 naming conventions

Sorry, instead of saying this I meant to say fall into the pit of success with concurrency and QOS. (http://blog.codinghorror.com/falling-into-the-pit-of-success/) The Foundation APIs such as -[NSData writeToURL:atomically:] are easy to find yet synchronous, and might be a newcomer’s first

Re: [swift-evolution] [Review] SE-0088: Modernize libdispatch for Swift 3 naming conventions

Oh man, this is fantastic! * What is your evaluation of the proposal? Great stuff, really brings dispatch into the world of Swift, and seems like it will not only make it more pleasant but better. I have a couple of questions: - Why is everything prefixed with Dispatch-, when you can surely

Re: [swift-evolution] [Review] SE-0088: Modernize libdispatch for Swift 3 naming conventions

Did not see this proposal coming down the pipeline, but a more Swift-like GCD will be fantastic. In terms of painting the bike shed, I'm not quite sure about having adverbs "synchronously" and "asynchronously" as method names. Conveniently, "sync" and "async" avoid the issue entirely, and they are

Re: [swift-evolution] [Review] SE-0088: Modernize libdispatch for Swift 3 naming conventions

I also think that this proposal highlights a reason why the stdlib should have some sort of 'indigenous' binary data capability, given that both Foundation and libdispatch would theoretically be able to leverage such a feature. Austin On Tue, May 10, 2016 at 10:22 PM, Austin Zheng

Re: [swift-evolution] [Review] SE-0088: Modernize libdispatch for Swift 3 naming conventions

I think this is a great idea and a great proposal. GCD is already a powerful, elegant tool available to Swift users, and this makes it feel even more Swift-like. Feedback/questions: - Is there a use case for user subclassing of a queue type? If not, should they be final? - Is there a reason to

Re: [swift-evolution] [Review] SE-0088: Modernize libdispatch for Swift 3 naming conventions

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0088-libdispatch-for-swift3.md 1. What is your evaluation of the proposal? +1. While I am not qualified on the