Awesome! :) You are too fast to follow up!
- Dennis
Sent from my iPhone
> On May 13, 2016, at 7:02 AM, Chris Lattner wrote:
>
> On May 12, 2016, at 12:59 AM, Dennis Weissmann via swift-evolution
> wrote:
let item = DispatchWorkItem(qos: .qosUserInitiated) {
print("Hello World")
On May 12, 2016, at 12:59 AM, Dennis Weissmann via swift-evolution
wrote:
>>> let item = DispatchWorkItem(qos: .qosUserInitiated) {
>>> print("Hello World")
>>> }
>>>
>>> I’d change the enum case from .qosUserInitiated to .userInitiated (maybe
>>> that’s just a typo since in the code exampl
- Dennis
> On May 12, 2016, at 9:34 AM, Pierre Habouzit wrote:
>
>> On May 11, 2016, at 9:02 AM, Dennis Weissmann via swift-evolution
>> mailto:swift-evolution@swift.org>> wrote:
>>
>> 1. What is your evaluation of the proposal?
>> +1 I think this is a big win for readability.
>>
>> 2. Is th
> On May 11, 2016, at 9:02 AM, Dennis Weissmann via swift-evolution
> wrote:
>
> 1. What is your evaluation of the proposal?
> +1 I think this is a big win for readability.
>
> 2. Is the problem being addressed significant enough to warrant a change to
> Swift?
> Yes. dispatch is used nearly e
> * What is your evaluation of the proposal?
I'm overall in favor.
I agree with the others who say that `synchronously` and `asynchronously` are
poor name choices. If we're going to deviate from the API guidelines, we should
at least choose names which have other desirable properties, lik
You do make some good points; we have a variety of important areas that are
completely unimplemented across any platforms, besides the feature parity
across platforms.
I also wonder why this can’t be provided as a new library on top of (rather
than as a replacement for) the existing libDispatch
My personal opinions, as someone who is relatively new to Swift and
libdispatch, but has spent some time playing with them recently ;)
>* What is your evaluation of the proposal?
Overall, I like the direction of the proposal. I think moving away from
the legacy C APIs will make libdispatch
1. What is your evaluation of the proposal?
+1 I think this is a big win for readability.
2. Is the problem being addressed significant enough to warrant a change to
Swift?
Yes. dispatch is used nearly everywhere so many many projects would benefit
from it.
3. Does this proposal fit well with t
> On May 11, 2016, at 6:34 AM, David Hart wrote:
>
> It sounds extreme to me to release a v1 of a library without giving yourself
> the flexibility to iterate on it beforehand.
Dispatch is already released (on two platforms). So that ship sailed in 2010.
The question in front of us is wheth
I completely disagree with what you said. It sounds extreme to me to release a
v1 of a library without giving yourself the flexibility to iterate on it
beforehand.
> On 11 May 2016, at 08:30, Drew Crawford via swift-evolution
> wrote:
>
> I'm one of the largest dispatch-on-linux users right n
On Wed, May 11, 2016 at 1:30 AM, Drew Crawford via swift-evolution <
swift-evolution@swift.org> wrote:
> I'm one of the largest dispatch-on-linux users right now. In fact, I'm
> reasonably sure I'm *THE* largest. I have an application in production
> that uses some 400 dispatch calls.
>
> On Lin
I'm one of the largest dispatch-on-linux users right now. In fact, I'm
reasonably sure I'm THE largest. I have an application in production that uses
some 400 dispatch calls.
On Linux, I'm running Swift 3 in production, essentially because Dispatch/Linux
in 2.2 does not even exist. On OSX/
12 matches
Mail list logo
