I just discovered this thread by accident - thank the Lord I’m not the only one who feels like this about the new Dispatch API!
> On 8 Jul 2016, at 04:16, Darren Mo via swift-evolution > <swift-evolution@swift.org> wrote: > > Should I create a bug report for changing `DispatchQueue.after` and > `DispatchSource.read`? > > Darren > >> On Jun 21, 2016, at 7:35 PM, Darren Mo <darren...@me.com >> <mailto:darren...@me.com>> wrote: >> >> On Jun 21, 2016, at 5:28 PM, Matt Wright <m...@apple.com >> <mailto:m...@apple.com>> wrote: >>>> On Jun 20, 2016, at 5:50 PM, Darren Mo via swift-evolution >>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>>> DispatchQueue.after(when:execute:) >>>> ---------------------------------- >>>> This one simply doesn’t read grammatically. For example, >>>> `queue.after(when: .now) { … }` becomes “queue, after when now …”. Since >>>> dispatch_after is semantically just an extended version of dispatch_async >>>> (I think), we can name this .executeAsync(after:_:). >>> >>> I replied to messages out of order but I agree, moving `.after` onto .async >>> seems like the more natural place for it to live. >> >> Yay! >> So long as the signature then reads grammatically - I had a little battle about this yesterday: http://comments.gmane.org/gmane.comp.lang.swift.evolution/23867 To summarise: - “after” should take a plain time interval - “deadline” is just simply the wrong word - means something else entirely - since we can’t take an interval without a clock, we need a default clock - but the nuances with those clocks are very important and a source of subtle bugs, so we should also ask for precise intention => I think we should split DispatchQueue.after() based on clock type. This would allow us to provide a default value for “now”, meaning we can also accept plain time intervals, as the resulting API would be explicit about the clock nuances that are often overlooked. >>>> DispatchSource subclass names >>>> ----------------------------- >>>> Why is it DispatchSourceMemoryPressure instead of >>>> MemoryPressureDispatchSource? I don’t think I’ve ever seen subclass names >>>> where the superclass part is at the beginning of the name. >>> >>> I’m not so keen to remove the Dispatch prefix from the front of the source >>> types, given that we avoided doing that for the remainder of the module. >> >> What is the rationale for keeping the Dispatch prefix anyways? (I couldn’t >> find it in the archives.) I would also like to know this. I really don’t like typing Dispatch... every time. It doesn’t seem to be very forgiving with code-completion. Also, dispatch code tends to contain a fair amount of nested closures. It’s nice to keep the line lengths short in that case. Karl
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
