Re: [swift-evolution] [Out of scope] Discussion on general Darwin/GlibC module

[Matt Wright via swift-evolution]

> On Nov 9, 2016, at 10:58 AM, Alex Blewitt via swift-evolution 
>  wrote:
> 
> Although out of scope for phase 1, something that keeps cropping up in a 
> variety of Linux/Darwin Swift scripts is the conditional inclusion of Darwin 
> or GlibC per platform. The last point was an observation that creating a 
> 'nice' wrapper for LibC or a cleaned up POSIX API is a non-goal:
> 
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20161003/027621.html

I appreciate the desire to have a combined module for this but I'm not 
convinced that `Libc` (or `LibC`) is a particularly good choice of name here. 
The `Lib` prefix feels particularly non-Swifty here, most other instances of 
lib on Darwin have their `lib` prefix dropped when imported as 
module. From a hierarchical point of view, the `Darwin` module encompasses a 
suite of libraries that are larger than libsystem_c.dylib (the Darwin Libc). 
Confusing the naming with layering here would be unfortunate. There's also a 
potentially confusing Darwin.C submodule that isn't what you're asking for but 
does step, somewhat, on the namespace.

Perhaps names more along the lines of `Platform` or `Base` would work better 
here? On Darwin the all-encompasing base libraries are all under Libsystem, 
`System` would be another potentially platform-agnostic name.

> 
>> I think it makes sense to have a cross platform “libc” which is an alias for 
>> darwin, glibc, or whatever, and just leave it at that.
>> 
>> Other proposals for a “POSIX” module have gotten bogged down because 
>> inevitably the idea comes up to make the resultant API nicer in various 
>> ways: rename creat, handle errno more nicely, make use of multiple return 
>> values, … etc.  The problem with this approach is that we don’t *want* 
>> people using these layer of APIs, we want higher level Foundation-like APIs 
>> to be used.
>> 
>> ...
>> 
>> 
>> I think we should formally decide that a “nice” wrapper for libc is a 
>> non-goal.  There is too much that doesn’t make sense to wrap at this level - 
>> the only Swift code that should be using this is the implementation of 
>> higher level API, and such extremely narrow cases that we can live with them 
>> having to handle the problems of dealing with the raw APIs directly.
>> 
>> -Chris
>> 
> 
> I have created a draft for a proposal to create such a module. Comments are 
> welcome.
> 
> Alex
> 
> ---
> 
> # Libc module for Swift
> 
> * Proposal: [SE-](-filename.md)
> * Authors: [Alex Blewitt](https://github.com/alblue)
> * Review Manager: TBD
> * Status: **Under discussion**
> 
> ## Introduction
> 
> When running on Darwin, the base module is called `Darwin`. When running
> on Linux or other operating systems, it's called `GlibC`. 
> 
> This repeatedly leads to code such as:
> 
> 
> #if os(Linux)
>   import Glibc
> #else
>   import Darwin
> #endif
> ```
> 
> As the set of operating systems evolve, one of these conditional imports
> needs to be updated. Instead of repeating this, make it available via a
> standard `Libc` module in the base Swift library.
> 
> Swift-evolution thread: [Discussion thread topic for that 
> proposal](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20161003/027621.html)
> 
> ## Motivation
> 
> The [set of 
> platforms](https://github.com/apple/swift/blob/fdf6ee20e4ca1fd32482f4b7b88a97ebdda52cd2/lib/Basic/LangOptions.cpp#L26-L36)
> that Swift currently runs on can be divided into two; Darwin and XNU based 
> systems
> (macOS, iOS, watchOS, tvOS), Windows, and Unix based systems
> (Linux, FreeBSD, Android, PS4). 
> 
> The base module on Darwin is called `Darwin`, while on Linux and
> other Unix systems the base module is called `Glibc`. The base
> module is typically conditionally included when working at a lower layer
> than Foundation (which has the same detail involved in importing the
> base module).
> 
> As a result, conditionally importing the right version typically uses
> a conditional test based on the operating system, and the same code is
> seen in a number of different modules, both internal to Swift and external:
> 
> * [Test for mmap in 
> stdlib](https://github.com/apple/swift/blob/07b196d2f9a5facc490b35e3649e18937796239b/test/stdlib/mmap.swift#L4-L9)
> * [Validation test for 
> PassIfChildCrashedDuringTestExecution](https://github.com/apple/swift/blob/c3b7709a7c4789f1ad7249d357f69509fb8be731/validation-test/StdlibUnittest/ChildProcessShutdown/PassIfChildCrashedDuringTestExecution.swift#L4-L9)
> * [Kitura's Socket 
> definitions](https://github.com/IBM-Swift/BlueSocket/blob/49c5af8b6953cecc8674a7fcf746fa27a72c056a/Sources/Socket.swift#L21-L25)
> * [Vapor's HTTP 
> Server](https://github.com/vapor/engine/blob/1f95094ee470408309e98dd56b2251210d6a2a3d/Sources/HTTP/Models/Server/HTTP%2BServer.swift#L1-L5)
> 
> Some have already created a `Libc` module that effectively does what this
> proposal suggests, such as [Vapor's Core 

Re: [swift-evolution] [SE-0088] Dispatch API names

[Matt Wright via swift-evolution]

> On Jul 14, 2016, at 3:44 AM, Karl  wrote:
> 
> 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 
>>  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  wrote:
>>> 
>>> On Jun 21, 2016, at 5:28 PM, Matt Wright  wrote:
> On Jun 20, 2016, at 5:50 PM, Darren Mo via swift-evolution 
>  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!
>>> 

To somewhat follow up on Darren’s suggestion: after internal discussion, moving 
`.after` into `.async` isn’t as good an idea as I had hoped. The behaviour of 
`.after`, both in execution and performance, differ substantially from `.async`.

> 
> 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.

I don’t think this topic needs forking and rehashing on this thread too.

> 
> 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.

This was covered somewhat during initial evolution, after discussion with the 
core team we decided to keep the Dispatch prefix. Several of the class names 
make more contextual sense with a Dispatch prefix, where they would not 
otherwise; Queues, Groups, etc. Secondly, Dispatch is implicitly imported by 
Foundation and we feel that keeping the prefix is clearer to the developer what 
it is you’re actually using.

> 
> 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

Re: [swift-evolution] [SE-0088] Dispatch API names

[Matt Wright via swift-evolution]

> On Jun 20, 2016, at 5:50 PM, Darren Mo via swift-evolution 
>  wrote:
> 
> SE-0088 was accepted with revisions a month ago. However, some of the APIs 
> just don’t feel right to me. I’ve only used DispatchQueue and DispatchSource 
> so far, so I will only comment on those.
> 
> DispatchQueue.async(execute:) and DispatchQueue.sync(execute:)
> --
> The lack of verb in the base name bothers me. The API Design Guidelines say 
> “methods with side-effects should read as imperative verb phrases”. You could 
> argue that the argument label “execute” serves as the verb. However, .async 
> and .sync are most commonly used with trailing closures where the argument 
> label is not present.
> 
> This issue was brought up during the review, but I did not see it being 
> addressed. Why not name the methods something like .executeAsync(_:) and 
> .executeSync(_:)?
> 
> 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.

> 
> 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.

> 
> DispatchSource factory methods
> --
> e.g. DispatchSource.read(fileDescriptor:queue:). The API Design Guidelines 
> mandate that factory methods begin with the prefix “make”. Indeed, 
> DispatchSource.read might mislead people to think that a read will be 
> performed by this method. A better name would be 
> .makeReadSource(fileDescriptor:queue:).

Agreed, these should probably be brought into line with that guideline.

> And why are these factory methods on DispatchSource instead of initializers 
> on the subclasses? ReadDispatchSource.init(fileDescriptor:queue:) would be 
> way clearer.

The source types are not subclasses, due to implementation details they are 
protocols.

> ___
> 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

Re: [swift-evolution] [SE-0088] Dispatch API names

[Matt Wright via swift-evolution]

> On Jun 20, 2016, at 7:12 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> 
> 
> On Mon, Jun 20, 2016 at 9:05 PM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> > DispatchQueue.async(execute:) and DispatchQueue.sync(execute:)
> > --
> > The lack of verb in the base name bothers me. The API Design Guidelines say 
> > “methods with side-effects should read as imperative verb phrases”. You 
> > could argue that the argument label “execute” serves as the verb. However, 
> > .async and .sync are most commonly used with trailing closures where the 
> > argument label is not present.
> >
> > This issue was brought up during the review, but I did not see it being 
> > addressed. Why not name the methods something like .executeAsync(_:) and 
> > .executeSync(_:)?
> 
> That feels a little redundant to me. It's worth remembering that the API 
> Guidelines are a means of creating clear APIs, not an end in themselves. It's 
> okay to deviate a little if you get a better result.
> 
> The guideline that methods should "read as imperative verb phrases" applies 
> to the full name, labels and arguments and all, and not just the base name. 
> You'll recall that the original proposal had .asynchronously(execute:), which 
> is very much an imperative phrase. `.async(execute:)` was substituted by 
> popular demand, with "async" being regarded as a term-of-art exception.

Right, the naming here strayed from the guidelines here under the term-of-art 
exception. None of the various alternatives really fit amazingly well, the 
async{,hronous} part of the API name communicates an important facet of what 
the call does. In that it goes away and executes the closure “somewhere else”. 
I feel this particular point is lost in example such as perform{andWait}. 
`.asynchronously` was an attempt to move towards the guidelines but it still 
missed that mark. I believe it’s still clearer to have `.async` as an exception.

> 
> However, I could see us borrowing (and slightly modifying) terminology from 
> Core Data:
> 
> queue.perform { … }
> queue.performAndWait { … }
> 
> Compared to the status quo, this is clearer, a better fit for the guidelines, 
> and better at penalizing the disfavored API.
> 
> > 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:_:).
> 
> Yeah, I gave a talk about the renaming on Saturday and somebody noted that 
> `when` reads poorly here. Fortunately, `queue.perform(after: .now() + 0.5)` 
> reads pretty well too. :^)
> 
> Or just `queue.after(_:execute:)`, i.e. "after [this time], execute [that 
> routine].”

.after is already going to need some tweaking as I don’t believe the current 
incarnation is sufficiently named to avoid being ambiguous in the common case. 
Though, removing the label will also not help in that regard. I agree, there is 
probably merit in the idea of moving after to being an optional argument on 
`.async`.

> 
> --
> Brent Royal-Gordon
> Architechies
> 
> ___
> 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

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

Re: [swift-evolution] libdispatch renaming feedback

[Matt Wright via swift-evolution]

> On Jun 15, 2016, at 11:14 AM, Guillaume Lessard via swift-evolution 
>  wrote:
> 
> Here’s some feedback after translating some Dispatch-heavy code for the new 
> Dispatch module.
> 
> 1. I like the result. Thanks for the effort!
> 
> 2. Omissions
> 
> - Can't initialize a new queue or obtain a global queue using a DispatchQoS 
> instance. [SR-1770]
> 
> One thing I have previously done was the following:
> 
> let anotherQueue: dispatch_queue_t = 
> let matchedQueue = 
> dispatch_get_global_queue(dispatch_queue_get_qos_class(anotherQueue, nil), 0)
> 
> There is no longer a way to do this.

Thanks for the feedback. I’ll take a look at getting something in that can do 
this.

> 
> Given that all the methods that enqueue blocks for execution have DispatchQoS 
> parameters, this must be an oversight (I didn’t notice it when reviewing the 
> proposal).
> 
> The following should exist:
> extension DispatchQueue {
>  init(qos: DispatchQoS, attributes: DispatchQueueAttributes)
>  class func global(qos: DispatchQoS, attributes: 
> DispatchQueue.GlobalAttributes) -> DispatchQueue
> }
> extension DispatchQueueAttributes {
>  // replacing dispatch_queue_attr_make_with_qos_class:
>  init(qos: DispatchQoS, attributes: DispatchQueueAttributes)
> }
> 
> - DispatchTime should be Comparable [SR-1771]

I’m curious why you need to compare DispatchTime values but if you can do this 
via rawValue it seems like it should be Comparable, even if I can’t bring to 
mind an immediately useful use-case.

> - qos_class_self() and qos_class_main() do not translate to DispatchQoS 
> [SR-1769]

SR-1769 has already been brought to my attention! I think that more or less 
covers all the comments you had about qos_class_t <-> DispatchQoS.

> 
> Since qos_class_t presumably isn’t disappearing (it’s used by Darwin 
> pthreads), the following are needed:
> 
> extension DispatchQoS {
>  static func current() -> DispatchQoS // equivalent to qos_class_self()
>  static var main: DispatchQoS // equivalent to qos_class_main()
>  init(qos: qos_class_t) // perhaps with a relativePriority?
> }
> 
> 3. Oddities
> 
> - DispatchQueueAttributes is top-level, while DispatchQueue.GlobalAttributes 
> is not.

I can’t immediately recall why I made this top-level but there was a technical 
problem with moving it into DispatchQueue. Perhaps that no longer exist, I’ll 
try again.

> 
> DispatchQueue.Attributes would look better to my eyes.
> 
> - Similarly, DispatchWorkItemFlags is top-level; it could perhaps be 
> DispatchWorkItem.Flags
> 
> - QualityOfService and DispatchQoS.QoSClass seem redundant. One of these 
> could probably go.
> (QualityOfService is defined under Foundation.NSObjCRuntime and is an enum 
> with rawValue)

There are backwards compatibility issues with combining 
Foundation.QualityOfService and DispatchQoS.QoSClass. For now they need to 
remain separate.

> 
> 
> 4. Bad translations or fixits
> 
> - dispatch_get_global_queue(qos_class_self(), 0) gets an invalid suggestion 
> (then again there is a void there, as noted above)
> 
> - dispatch_block_create does not have a fixit pointing to the new 
> DispatchWorkItem type.
> 
> 
> Cheers,
> Guillaume Lessard
> 
> ___
> 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

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

[Matt Wright via swift-evolution]

> 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; `dispatchSynchronously` or `dispatchSync` (or `performSync` or 
> `performSynchronously`) all seem more-appropriate.
> 
> I understand the impetus behind having fewer core methods, but IMHO the 
> `dispatch_barrier_sync` and `dispatch_barrier_async` calls ought to have 
> direct equivalents here (even if they are just sodlib-supplied conveniences 
> that call through to the unified method).

I don’t see having barrier as separate methods as a particularly good fit for 
Swift. Given that there are other options surrounding how a block operates when 
it is executed, it makes more sense as default parameters to the same methods. 
This avoids having to have variants of the block submission methods for both 
barrier, QoS, both, etc.

> 
> I also don’t see `dispatch_apply` here anywhere; intentional? Ideally it’d be 
> @noescape, but handling `throw` / `rethrow` for that function in this case 
> seems complicated.

This is here in the updated version, though I agree it’s not simple to handle 
throwing out of the block as multiple threads are executing the same code at 
once.

> 
> This next one is subjective, but I find the placement of the group-related 
> methods somewhat backwards vis-a-vis how I think of them in terms of the 
> C-API.

I suspect this can go either way but the block is still being executed on a 
given queue, you’re just associating the execution of that block with a given 
group. In my mind that lives on the queue, as the execution will still occur 
there. Contrasting this to notify, which requests that the group itself submits 
the notify block to the queue when the group itself is empty.

> 
> EG: I think of `dispatch_group_async` as a “method” on a `dispatch_group`, so 
> would’ve expected this:
> 
> class DispatchGroup : DispatchObject {
> 
>  // (actual name should match chosen name convention)
>  func asynchronouslyDispatch(to queue: DispatchQueue, work: 
> @convention(block) () -> Void)
> 
>  // (actual name should match chosen name convention)
>  func notify(on queue: DispatchQueue, using block: @convention(block) () -> 
> Void)
> 
> }
> 
> …(and presumably the API would have manual enter/leave/wait methods and so on 
> exposed).
> 
> I don’t feel strongly here but bring it up in case others feel similarly.
> 
> I’m a little confused about the `DispatchSpecificKey` class; is it 
> anything more than a way to "smuggle in” a generic type parameter for the 
> associated value? 

I think it’s a little stronger than “smuggle in” here, it allows the compiler 
to enforce that you have the same type going into setSpecific that you get out 
of getSpecific (or DispatchQueue.getSpecific) for a given key. The C API here 
forces you to cast away from void* and I think this is a good example of how 
the Swift equivalent API is helping make things safer.

> 
> Also on queue-specifics, what is our expected story if we have custom 
> destructors? Subclass `DispatchSpecificKey`? 

The value supplied to setSpecific is boxed inside a class that’s then retained. 
When the queue is deallocated, or the value is replaced then the box is 
released and normal Swift semantics for memory management will kick in on your 
boxed value. That way the API is still flexible enough to consume non-objects, 
like Ints, but also capable of taking references to classes too.

> 
> For things like `Int` specifics, I assume this API is storing auto-boxed 
> values…? Is there any way to side-step if we use want to store an unsafe 
> pointer? It’s not a big deal for me if we can’t under this API, TBH, but I’d 
> at least like to see this API’s implementation and costs spelled-out more 
> explicitly.
> 
> For `DispatchData`, is there a principled reason there isn’t something like 
> this defined:
> 
> struct DispatchDataSegment {
>  let bytes: UnsafeBufferPointer
>  let byteIndex: Int
> }
> 
> extension DispatchData {
> 
>  /// Returns a sequence that enumerates the contiguous chunks,
>  /// e.g. a sequence with elements of type `DispatchDataSegment`.
>  ///
>  /// Sequence-based eplacement-for `enumerateBytes(_:)`
>  var segmentSequence: DispatchDataSegmentSequence { get }
> 
> }

This is a good path to investigate in future improvements here.

> 
> …or something analogous (instead of the proposed use dispatch_data_apply?)? 
> 
> I don’t see any API yet for setting target queues, or getting queue labels. I 
> know the proposal isn’t documenting the APIs in full but it’s hard to 
> evaluate in that absence.
> 
> I don’t see basic API on dispatch sources yet for things like setting event 
> handlers, (etc.); again I know the APIs aren’t fully specified here but it’s 
> hard to evaluate something that’s not fully specified.

These should be present in 

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

[Matt Wright via swift-evolution]

> On May 13, 2016, at 12:24 PM, Jacob Bandes-Storch <jtban...@gmail.com> 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 addresses both the initial setup as well as setting it again. I’m not 
sure reset is a good name for it.

> - Consider making Semaphore's wait() throw an error, rather than returning 
> non-zero, in the event of a timeout. Most common uses will be "try! wait()". 
> Or you could have waitForever() be a separate, non-throwing function.

Throwing an error here seems like a sensible improvement.

> 
> Jacob Bandes-Storch
> 
> On Fri, May 13, 2016 at 11:36 AM, Matt Wright via swift-evolution 
> <swift-evolution@swift.org> wrote:
> [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 have been applied. Additionally, I’ve been 
> keeping up with some of the feedback in this review thread and looking to see 
> which ones would be best applied to the proposal. Though it should be made 
> clear, this particular update only covers fixing the inconsistencies in my 
> original proposal and providing a more complete overview of the module layout.
> 
> Similar to the changes in Foundation that are proposed on swift-evolution, I 
> don’t expect all of the changes in libdispatch will be able to go through 
> this process. As this is a large change (and, hopefully, a step forwards) to 
> libdispatch I believe it is important to bring it to the swift-evolution list 
> and take away your feedback for inclusion in future iterations of the module.
> 
> Thanks again for your continued feedback,
> Matt
> 
> > On Tue, May 10, 2016 at 9:39 PM, Chris Lattner via swift-evolution 
> > <swift-evolution@swift.org> wrote:
> > Hello Swift community,
> >
> > The review of "SE-0088: Modernize libdispatch for Swift 3 naming 
> > conventions" begins now and runs through May 17. The proposal is available 
> > here:
> >
> > 
> > https://github.com/apple/swift-evolution/blob/master/proposals/0088-libdispatch-for-swift3.md
> >
> > Reviews are an important part of the Swift evolution process. All reviews 
> > should be sent to the swift-evolution mailing list at
> >
> > https://lists.swift.org/mailman/listinfo/swift-evolution
> >
> > or, if you would like to keep your feedback private, directly to the review 
> > manager.
> >
> > What goes into a review?
> >
> > The goal of the review process is to improve the proposal under review 
> > through constructive criticism and contribute to the direction of Swift. 
> > When writing your review, here are some questions you might want to answer 
> > in your review:
> >
> > * What is your evaluation of the proposal?
> > * Is the problem being addressed significant enough to warrant a 
> > change to Swift?
> > * Does this proposal fit well with the feel and direction of Swift?
> > * If you have used other languages or libraries with a similar 
> > feature, how do you feel that this proposal compares to those?
> > * How much effort did you put into your review? A glance, a quick 
> > reading, or an in-depth study?
> >
> > More information about the Swift evolution process is available at
> >
> > https://github.com/apple/swift-evolution/blob/master/process.md
> >
> > Thank you,
> >
> > -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
> 
> ___
> 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

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

[Matt Wright via swift-evolution]

> On May 13, 2016, at 12:29 PM, Xiaodi Wu <xiaodi...@gmail.com> 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 setLowWater can probably become setLimit(highWater:) 
setLimit(lowWater:). setTargetQueue -> setTarget(queue:) seems like an obvious 
change but something about it doesn’t sit particularly right with me. I will 
think about this further. There were both very useful bits feedback on these 
names though, thank you!

> Similarly, in terms of conforming to Swift guidelines, I notice many 
> instances where labels repeat the parameter type, especially 
> DispatchWalltime. For instance, setTimer(walltime: DispatchWalltime, leeway: 
> DispatchTimeInterval)--not sure what to suggest here other than point out 
> that the first label is redundant.

setTimer() in particular has a setTimer(start:,…) and setTimer(walltime:,…) 
that are distinct, perhaps the latter could be `walltimeStart:`. While there 
was an earlier argument for removing Walltime as a typed concept, we believe it 
is advantageous to keep different “types” of time as separate distinct Swift 
types in the module.

> On Fri, May 13, 2016 at 11:36 Matt Wright via swift-evolution 
> <swift-evolution@swift.org> wrote:
> [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 have been applied. Additionally, I’ve been 
> keeping up with some of the feedback in this review thread and looking to see 
> which ones would be best applied to the proposal. Though it should be made 
> clear, this particular update only covers fixing the inconsistencies in my 
> original proposal and providing a more complete overview of the module layout.
> 
> Similar to the changes in Foundation that are proposed on swift-evolution, I 
> don’t expect all of the changes in libdispatch will be able to go through 
> this process. As this is a large change (and, hopefully, a step forwards) to 
> libdispatch I believe it is important to bring it to the swift-evolution list 
> and take away your feedback for inclusion in future iterations of the module.
> 
> Thanks again for your continued feedback,
> Matt
> 
> > On Tue, May 10, 2016 at 9:39 PM, Chris Lattner via swift-evolution 
> > <swift-evolution@swift.org> wrote:
> > Hello Swift community,
> >
> > The review of "SE-0088: Modernize libdispatch for Swift 3 naming 
> > conventions" begins now and runs through May 17. The proposal is available 
> > here:
> >
> > 
> > https://github.com/apple/swift-evolution/blob/master/proposals/0088-libdispatch-for-swift3.md
> >
> > Reviews are an important part of the Swift evolution process. All reviews 
> > should be sent to the swift-evolution mailing list at
> >
> > https://lists.swift.org/mailman/listinfo/swift-evolution
> >
> > or, if you would like to keep your feedback private, directly to the review 
> > manager.
> >
> > What goes into a review?
> >
> > The goal of the review process is to improve the proposal under review 
> > through constructive criticism and contribute to the direction of Swift. 
> > When writing your review, here are some questions you might want to answer 
> > in your review:
> >
> > * What is your evaluation of the proposal?
> > * Is the problem being addressed significant enough to warrant a 
> > change to Swift?
> > * Does this proposal fit well with the feel and direction of Swift?
> > * If you have used other languages or libraries with a similar 
> > feature, how do you feel that this proposal compares to those?
> > * How much effort did you put into your review? A glance, a quick 
> > reading, or an in-depth study?
> >
> > More information about the Swift evolution process is available at
> >
> > https://github.com/apple/swift-evolution/blob/master/process.md
> >
> > Thank you,
> >
> > -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
> 
> ___
> 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

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

[Matt Wright via swift-evolution]

[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 have been applied. Additionally, I’ve been 
keeping up with some of the feedback in this review thread and looking to see 
which ones would be best applied to the proposal. Though it should be made 
clear, this particular update only covers fixing the inconsistencies in my 
original proposal and providing a more complete overview of the module layout.

Similar to the changes in Foundation that are proposed on swift-evolution, I 
don’t expect all of the changes in libdispatch will be able to go through this 
process. As this is a large change (and, hopefully, a step forwards) to 
libdispatch I believe it is important to bring it to the swift-evolution list 
and take away your feedback for inclusion in future iterations of the module.

Thanks again for your continued feedback,
Matt

> On Tue, May 10, 2016 at 9:39 PM, Chris Lattner via swift-evolution 
>  wrote:
> Hello Swift community,
> 
> The review of "SE-0088: Modernize libdispatch for Swift 3 naming conventions" 
> begins now and runs through May 17. The proposal is available here:
> 
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0088-libdispatch-for-swift3.md
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager.
> 
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and contribute to the direction of Swift. When 
> writing your review, here are some questions you might want to answer in your 
> review:
> 
> * What is your evaluation of the proposal?
> * Is the problem being addressed significant enough to warrant a 
> change to Swift?
> * Does this proposal fit well with the feel and direction of Swift?
> * If you have used other languages or libraries with a similar 
> feature, how do you feel that this proposal compares to those?
> * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?
> 
> More information about the Swift evolution process is available at
> 
> https://github.com/apple/swift-evolution/blob/master/process.md
> 
> Thank you,
> 
> -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

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

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

[Matt Wright via swift-evolution]

> 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 qualify both
> `Dispatch.Data` and `Foundation.Data` would be an issue. If libdispatch
> had originally been part of Foundation, you'd need prefixes anyway:
> 
> * DispatchQueue
> * NotificationQueue
> * OperationQueue
> 
> ## Quality of Service
> 
> Should argument labels and type names match those in Foundation?
> 
> * qos:=> qualityOfService:
> * DispatchQoS => DispatchQualityOfService
> 
> Could there be a shared `Swift.QualityOfService` enum?
> 
> * QOS_CLASS_DEFAULT = 0x15
> * NSQualityOfServiceDefault = -1
> 
> The `.unspecified` QoS is not defined in NSQualityOfService.
> Would an optional QoS parameter (defaulting to nil) be better?
> 
> ## Time
> 
> The `dispatch_time` function uses a nanoseconds delta, so the operator
> overloads taking `seconds: Double` might be ambiguous at the call site.
> You could try changing the associated value types of your enum.
> 
> ```
> enum DispatchTimeInterval {
>case  seconds(Double) // changed from `Int`
>case milliseconds(Int64)  // changed from `Int`
>case microseconds(Int64)  // changed from `Int`
>case  nanoseconds(Int64)  // changed from `Int`
> }
> 
> let _ = DispatchTime.now + 3.5 // ambiguous?

Are you talking about ambiguity at a compiler level, or in human-reading? The 
other four examples are an addition with an enum type, the first one is a 
double. There’s no compiler ambiguity here.

> let a = DispatchTime.now +  .seconds(3.5)
> let b = DispatchTime.now + .milliseconds(3_500)
> let c = DispatchTime.now + .microseconds(3_500_000)
> let d = DispatchTime.now +  .nanoseconds(3_500_000_000)
> ```
> 
> Is the `DispatchTime.now` in your example a type property?

DispatchTime.now() is a function that returns the current time. The subsequent 
examples are typos (now() became a method quite late in the proposal’s 
development) and I’ll fix it up before pushing a v2 proposal that’s fixed up a 
lot of the typos that arose from late changes.

> 
> ## Data
> 
> Should the `DispatchData.append` methods have `contentsOf:` labels?
> Or could it conform to the RangeReplaceableCollection protocol?
> 
> ## Queues
> 
> My suggestions for the async/sync methods:
> 
> * enqueue(...)
> * enqueueAndWaitUntilFinished(...)
> 
> -- Ben
> 
> 
> ___
> 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

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

[Matt Wright via swift-evolution]

> 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 simpler), but I'm hoping this 
> proposal can go through another round or two of 
> discussion/bikeshedding/revision before approval.
> 
> (Small note: I'm really happy about the strong-typed-ness of the Source 
> subclasses, e.g. how mergeData is only available for Add/Or.)
> 
> In no particular order, here are some things on which I'm unclear, or 
> not-so-+1:
> 
> - synchronously()'s block parameter should be @noescape. Perhaps more 
> arguably, it should have a generic return type and rethrows, like 
> autoreleasepool now does.

Both of these are present in the changes I have for this proposal. The former 
point is a mistake in my proposal text, the latter is an unfortunate oversight 
on my part in putting together the proposal document.

> - The names asynchronously(execute:) and synchronously(execute:) don't seem 
> to fit with any API guidelines I'm aware of. Did you consider including the 
> verb in the method name?  

We did. Of the number of names that we discussed, none of them were perfect. 
sync/async are common in other languages but don’t fit the general direction of 
the Swift 3 naming conventions. Using `dispatchAsynchronously` is an extremely 
long method name, even more so than `asynchronously`. `perform` does not 
capture the sync/async nature of the calls particularly well, compared to 
DispatchWorkItem where `perform` immediately executes the block.

> (And I'm guessing that "func synchronously(work:...)" is meant to be "func 
> synchronously(execute work:...)”?)

Right.

> As another bikeshed-item, I'd vote for "Data.init(withoutCopying:...)" rather 
> than "(bytesNoCopy:...)", and perhaps whenDone() instead of notify().

Here the init() functions closely mirror Data from Foundation, the Objective-C 
class is toll-free bridged to NSData and we desired a close match to the 
Foundation Swift API. `notify` is Dispatch-only API though, I’ll go think over 
that one.

> - Are DispatchWorkItemFlags meant to overlay dispatch_block_flags? It would 
> be nice to explicitly list these in the proposal.

The dispatch_block_* API is completely superseded by DispatchWorkItem in the 
proposal. DispatchWorkItemFlags is the equivalent to dispatch_block_flags.

> - Are functions like dispatch_barrier_sync totally gone in favor of passing a 
> .barrier flag? It would be nice to explicitly state this in the proposal.

Yes, you can supply .barrier to either `synchronously` or `asynchronously`, or 
create a DispatchWorkItem as a barrier item. Where possible the multiple 
variants of a class (dispatch_async, dispatch_barrier_async, etc) are collapsed 
into a single method with default arguments.

> - I echo Austin's concerns about subclassability. I think it would be 
> dangerously misleading if the classes were subclassable from user code, even 
> if it didn't work properly.

Building at compile time will fail. So you wouldn’t get very far trying to use 
them, I plan to investigate adding `final` here (it’s only absent for technical 
reasons, as the classes originate from Objective-C).

> - What of the APIs provided on Semaphore and Group objects? I'd like to see 
> these before I vote for the proposal.

These would be transformed similarly, I will include them when updating the 
proposal.

class DispatchSemaphore : DispatchObject {  
   

  init(value: Int)

  func wait(timeout: DispatchTime = default) -> Int

  func wait(walltime timeout: DispatchWalltime) -> Int

  func signal() -> Int

}

class DispatchGroup : DispatchObject {

  init()


  func wait(timeout: DispatchTime = default) -> Int

  func wait(walltime timeout: DispatchWalltime) -> Int

  func notify(queue: DispatchQueue, block: () -> Void)

  func enter()

  func leave()

}


> - What will dispatch_set_target_queue's replacement look like look like?

extension DispatchObject {  
   

  func setTargetQueue(queue: DispatchQueue?)

}

> 
> - What about dispatch_once?

Removed. Swift already has lazy initialisation at the language level, 
dispatch_once is neither needed nor safe in Swift.

> - Why use class funcs for the Source initializers, rather than an init on 
> each individual subclass?

Implementation limitations. The “subclasses" are protocols would be introduced 
in order to attain a level of type safety around DispatchSource. We felt this 
was a significant enough improvement that it was worth including even 

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

[Matt Wright via swift-evolution]

> 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.
> 
> Feedback/questions:
> - Is there a use case for user subclassing of a queue type? If not, should 
> they be final?

Currently it’s not possible to subclass these classes in Objective C either, 
the metaclass symbols for the libdispatch Objective-C classes are not exported. 
This same restriction applies to those classes when interacting with them in 
swift, even though the classes themselves are not marked `final`.

> - Is there a reason to use class methods rather than static methods for the 
> queue types? I was under the impression that static methods would be 
> preferred unless a good reason exists to dispatch upon metatype.

This detail passed me by, I will investigate.

> - Nit: "DispatchWallTime" is spelled "DispatchWalltime" (lowercase 't') in 
> the code samples.

I apologise, along with the one or two other spelling/naming issues others have 
pointed out. One or two of these names changed recently and I clearly didn’t 
catch all of them.

> - Is it allowed/technically possible for non-stdlib code to use 
> _ObjectiveCBridgable?

Similar to the Foundation mutability proposal, this will end up being an 
internal implementation detail of DispatchData’s struct bridging.

Regards,
M

> 
> Best,
> Austin
> 
> 
> On Tue, May 10, 2016 at 9:39 PM, Chris Lattner via swift-evolution 
>  wrote:
> Hello Swift community,
> 
> The review of "SE-0088: Modernize libdispatch for Swift 3 naming conventions" 
> begins now and runs through May 17. The proposal is available here:
> 
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0088-libdispatch-for-swift3.md
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager.
> 
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and contribute to the direction of Swift. When 
> writing your review, here are some questions you might want to answer in your 
> review:
> 
> * What is your evaluation of the proposal?
> * Is the problem being addressed significant enough to warrant a 
> change to Swift?
> * Does this proposal fit well with the feel and direction of Swift?
> * If you have used other languages or libraries with a similar 
> feature, how do you feel that this proposal compares to those?
> * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?
> 
> More information about the Swift evolution process is available at
> 
> https://github.com/apple/swift-evolution/blob/master/process.md
> 
> Thank you,
> 
> -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

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