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

[Dennis Weissmann via swift-evolution]

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")
 }
 
 I’d change the enum case from .qosUserInitiated to .userInitiated (maybe 
 that’s just a typo since in the code example before uses .unspecified).
>>> 
>>> I think it is a typo, only default needs to be qosDefault because default 
>>> is a keyword, and asking all users to back-tick it isn’t really good either.
>>> (also no one should really specify qos class default anyway).
>> 
>> Even .default should be okay once SE-0071 is implemented.
> 
> SE-0071 is implemented already.
> 
> -Chris


smime.p7s
Description: S/MIME cryptographic signature
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Chris Lattner via swift-evolution]

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 example before uses .unspecified).
>> 
>> I think it is a typo, only default needs to be qosDefault because default is 
>> a keyword, and asking all users to back-tick it isn’t really good either.
>> (also no one should really specify qos class default anyway).
> 
> Even .default should be okay once SE-0071 
> 
>  is implemented.

SE-0071 is implemented already.

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

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

[Dennis Weissmann via swift-evolution]

- 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 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 the feel and direction of Swift?
>> Making the API more “swift" and feel more natural definitely is the 
>> direction Swift libraries are / should be going in.
>> 
>> 4. If you have used other languages or libraries with a similar feature, how 
>> do you feel that this proposal compares to those?
>> Unfortunately not.
>> 
>> 5. How much effort did you put into your review? A glance, a quick reading, 
>> or an in-depth study?
>> Read the proposal twice.
>> 
>> A little nitpick:
>> 
>> 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 example before uses .unspecified).
> 
> I think it is a typo, only default needs to be qosDefault because default is 
> a keyword, and asking all users to back-tick it isn’t really good either.
> (also no one should really specify qos class default anyway).

Even .default should be okay once SE-0071 

 is implemented.

>> 
>> - Dennis
>> 
>>> On May 11, 2016, at 6:39 AM, Chris Lattner >> > 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-announce mailing list
>>> swift-evolution-annou...@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution-announce
>> 
>> ___
>> 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] [swift-evolution-announce] [Review] SE-0088: Modernize libdispatch for Swift 3 naming conventions

[Pierre Habouzit via swift-evolution]

> 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 everywhere so many many projects would benefit 
> from it.
> 
> 3. Does this proposal fit well with the feel and direction of Swift?
> Making the API more “swift" and feel more natural definitely is the direction 
> Swift libraries are / should be going in.
> 
> 4. If you have used other languages or libraries with a similar feature, how 
> do you feel that this proposal compares to those?
> Unfortunately not.
> 
> 5. How much effort did you put into your review? A glance, a quick reading, 
> or an in-depth study?
> Read the proposal twice.
> 
> A little nitpick:
> 
> 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 example before uses .unspecified).

I think it is a typo, only default needs to be qosDefault because default is a 
keyword, and asking all users to back-tick it isn’t really good either.
(also no one should really specify qos class default anyway).

> 
> - Dennis
> 
>> On May 11, 2016, at 6:39 AM, Chris Lattner > > 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-announce mailing list
>> swift-evolution-annou...@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution-announce
> 
> ___
> 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] [swift-evolution-announce] [Review] SE-0088: Modernize libdispatch for Swift 3 naming conventions

[Brent Royal-Gordon via swift-evolution]

>   * 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, like brevity or 
matching existing terms of art. These names don't. I would prefer `sync` and 
`async`, or if necessary, `dispatchSync` and `dispatchAsync`.

I'm very impressed by the way the "specific" APIs have been translated to 
Swift, but I think the method names are wrong, particularly the `get` method. 
Ideally these would be a subscript, but we don't have generic subscripts yet. 
Failing that, I suggest using `specificValue(for key:)` and `setSpecificValue(_ 
value: for key:)`. I'm also worried about how this will interoperate with 
Objective-C: Will there be some way to smuggle one of the arbitrary Objective-C 
pointers for this API into Swift as a DispatchSpecificKey, or vice versa?

>   * Is the problem being addressed significant enough to warrant a change 
> to Swift?

Yes. libdispatch is pretty awkward even in Objective-C, let alone in Swift.

>   * Does this proposal fit well with the feel and direction of Swift?

Yes.

>   * If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?

N/A.

>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?

Quick reading.

-- 
Brent Royal-Gordon
Architechies

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

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

[Russ Bishop via swift-evolution]

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 C interface. I have my own 
DispatchQueue class that does a lot of what this proposal suggests but it 
doesn’t replace the dispatch_* calls so it doesn’t break anything.

We are starting to accumulate a massive number of breaking changes. Yes there 
are fix-its but you still have problems with branches and coordinating the 
upgrade.

I’m also sympathetic to the fact that any changes we want to make will only get 
more difficult with time and the longer we wait to refactor APIs, rename 
things, etc the less likely it will even be possible. I think part of the rush 
for these kinds of changes is the fact that Swift 3 wants to focus on ABI 
stability and a lot of people are interpreting that as “this is our last chance 
to fix everything we don’t like!”, though ABI stability != API stability. Might 
just be me though.


Russ


> On May 10, 2016, at 11:30 PM, Drew Crawford via swift-evolution 
>  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 Linux, I'm running Swift 3 in production, essentially because 
> Dispatch/Linux in 2.2 does not even exist.  On OSX/iOS, I compile the same 
> codebase with Swift 2.2, because that's the version that's released, and 
> using released software is a sane thing to do.
> 
> This proposal places me in the uncomfortable situation of trying to somehow 
> smooth out a truly MASSIVE API delta with #if.  And that's not going to 
> happen.  Realistically, what I will do is create some kind of FrankenSwift 
> that either backports the new API to Swift 3 or the old API to Swift 2.  And 
> that is a ton of work, really stupid work, and I would infinitely prefer to 
> spend that time doing something actually useful to the world.  To be clear, I 
> don't fear migration; what I fear is the heisenmigration, where one of my 
> platforms must migrate, and the other ones can't.
> 
> More broadly, I am concerned about the direction the language is going where 
> we do not even have working libraries yet and already we are doing sweeping 
> API changes to them.  I suspect this is motivated by a fundamentally 
> incorrect premise–the premise that because it's not released yet, we can get 
> away with it.  When actually that's backwards: we can get away with breaking 
> changes later, but if we do them now we will ruin everything.  Let me explain.
> 
> Right now, Linux Swift programmers exist. And they need to be able to solve 
> ordinary problems, like writing a string to a file, or spinning up a 
> background thread.  And I do mean: sometime before Late 2016.  No amount of 
> telling them "don't do that, it's not released" is going to stop this.  The 
> only question is whether upstream is going to be the repo that solves their 
> problem, or whether they go to solve the problem somewhere else.  Because 
> when they go somewhere else, they invest there.
> 
> Increasingly, because upstream is not interested in the problem, I am seeing 
> Linux folk go solve the problem somewhere else.  Just counting the projects 
> I'm personally aware of, there are 3 foundation alternatives and 1 package 
> manager alternative.  All because upstream has no sane path to e.g. reading a 
> file on disk in the kind of timeframe working programmers actually need to do 
> it in.
> 
> What we *should* be doing is creating libraries that *work*, *releasing 
> them*, and then we can do as much API Disneyland as we want without harassing 
> the working programmer.
> 
> 1.  If we're out of bugs to fix, why not release?  Then folks like me can get 
> off the snapshot treadmill and we won't be annoyed by massive API delta until 
> we can do it all at once, which is (relatively) easy.
> 2.  If we're not out of bugs to fix, why not work on them, and then release, 
> and then come back to this?
> 3.  Since Swift 3 will have a stable ABI, why not ship both libdispatch2 and 
> libdispatch3 and let the programmer plan her own migration?  I'm not even 
> sure the stable ABI part is relevant, since Dispatch is almost entirely C.
> 
> All of these are saner alternatives to the proposal, and all of them achieve 
> the stated goal (e.g. we still end up with happy modern APIs).
> 
> I don't mean to pick on this proposal specifically, I agree with the need to 
> modernize the API surface area.  But if we continue to do breaking changes 
> first and releases later I'm concerned about where the early adopters will 
> get pushed to.
> 
> Drew
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinf

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

[David P Grove via swift-evolution]

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 in Swift more accessible and
pleasant to use.

I would like to see more details on how the overlay will be implemented on
platforms without Objective-C.  Specifically, since libdispatch is mostly a
C library, it seems to me that this would be a good opportunity to purge
Objective-C from the libdispatch implementation entirely and have a simpler
and more portable Swift + C implementation.  That is what we have to do for
Linux, so let's eliminate some of the platform differences and do it
everywhere.  However, that may be at odds with the "without adding runtime
overhead" objective of the proposal.  I made an attempt earlier this spring
to get libdispatch's C structs to masquerade as Swift classes (instead of
Objective-C classes as they currently do when Objective-C is available).  I
gave up because some of the implementation tricks used in libdispatch's
queues made it a fairly invasive change.  However, others more skilled in
Swift+libdispatch might be able to pull it off.  Is the implementation plan
to write a fairly thick Swift layer that wraps primitive C types, or is it
something else?

Echoing others, I would keep sync/async as names in the APIs. These are
well known terms that are used in many similar tasking libraries in other
languages; they are also familiar to current libdispatch users.

I would like to see a statically checkable distinction in the API between
Darwin-specific functionality and the APIs that are truly cross platform.
This mainly shows up in the DispatchSources portion of the API.  Tag
methods of DispatchSource with availability macros or similar?

It seems overly verbose to prefix all the types with Dispatchis this
really necessary?


>* Is the problem being addressed significant enough to warrant a
change to Swift?

From a Linux perspective, the existing Swift libdispatch API is badly
incomplete. The lack of Objective-C on Linux results in a poor quality
import of the dispatch headers.  Something needs to be done in the Swift 3
time frame to fix this.  We could get by with a less sweeping change than
this proposal, but something does need to be done.

Ideally, the new overlay would also be back-ported to Swift 2.2 to address
Drew's valid concerns about maintaining cross-platform code that uses
libdispatch during the transition from Swift 2.2 to Swift 3.

>* Does this proposal fit well with the feel and direction of Swift?

Yes (but I am newish to Swift...).

>* If you have used other languages or libraries with a similar
> feature, how do you feel that this proposal compares to those?

It should get libdispatch in Swift to be roughly on par with the
integrated experience one gets from using tasking libraries in other modern
object-oriented languages with closures.

>* How much effort did you put into your review? A glance, a quick
> reading, or an in-depth study?

Read proposal carefully.  Have thought about the issues quite a bit
recently.

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

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

[Dennis Weissmann via swift-evolution]

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 the feel and direction of Swift?
Making the API more “swift" and feel more natural definitely is the direction 
Swift libraries are / should be going in.

4. If you have used other languages or libraries with a similar feature, how do 
you feel that this proposal compares to those?
Unfortunately not.

5. How much effort did you put into your review? A glance, a quick reading, or 
an in-depth study?
Read the proposal twice.

A little nitpick:

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 example before uses .unspecified).

- Dennis

> On May 11, 2016, at 6:39 AM, Chris Lattner  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-announce mailing list
> swift-evolution-annou...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution-announce

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

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

[Drew Crawford via swift-evolution]

> 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 whether we're going to focus in getting the 
Linux port to parity with Darwin or whether we're going off an an API design 
adventure before seriously addressing that goal.

It seems prudent to point out that "API design" appears last on our list of 
Swift 3 goals, while "Portability " 
is in the top three.  So I don't know why my position would be "extreme", as it 
is more consistent with what we are on paper supposed to be doing in this 
release.

It also seems prudent to point out that we are going to do the first preview 
branch tomorrow.  Obviously none of us really know what to expect, but the 
official guidance includes such statements as "only changes that align with the 
core goals of the release will be considered" and "Source-breaking changes to 
the language will be considered on a case-by-case basis."  I think we should 
consider whether rewriting the entire Dispatch API surface area is something 
that would clear that bar.

I agree with all the individual API changes.  They're great.  I just think the 
timing is wrong.  We should get to Darwin parity, and then we'll be in a 
position to pull the trigger on this.

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

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

[David Hart via swift-evolution]

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 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/iOS, I compile the same 
> codebase with Swift 2.2, because that's the version that's released, and 
> using released software is a sane thing to do.
> 
> This proposal places me in the uncomfortable situation of trying to somehow 
> smooth out a truly MASSIVE API delta with #if.  And that's not going to 
> happen.  Realistically, what I will do is create some kind of FrankenSwift 
> that either backports the new API to Swift 3 or the old API to Swift 2.  And 
> that is a ton of work, really stupid work, and I would infinitely prefer to 
> spend that time doing something actually useful to the world.  To be clear, I 
> don't fear migration; what I fear is the heisenmigration, where one of my 
> platforms must migrate, and the other ones can't.
> 
> More broadly, I am concerned about the direction the language is going where 
> we do not even have working libraries yet and already we are doing sweeping 
> API changes to them.  I suspect this is motivated by a fundamentally 
> incorrect premise–the premise that because it's not released yet, we can get 
> away with it.  When actually that's backwards: we can get away with breaking 
> changes later, but if we do them now we will ruin everything.  Let me explain.
> 
> Right now, Linux Swift programmers exist. And they need to be able to solve 
> ordinary problems, like writing a string to a file, or spinning up a 
> background thread.  And I do mean: sometime before Late 2016.  No amount of 
> telling them "don't do that, it's not released" is going to stop this.  The 
> only question is whether upstream is going to be the repo that solves their 
> problem, or whether they go to solve the problem somewhere else.  Because 
> when they go somewhere else, they invest there.
> 
> Increasingly, because upstream is not interested in the problem, I am seeing 
> Linux folk go solve the problem somewhere else.  Just counting the projects 
> I'm personally aware of, there are 3 foundation alternatives and 1 package 
> manager alternative.  All because upstream has no sane path to e.g. reading a 
> file on disk in the kind of timeframe working programmers actually need to do 
> it in.
> 
> What we *should* be doing is creating libraries that *work*, *releasing 
> them*, and then we can do as much API Disneyland as we want without harassing 
> the working programmer.
> 
> 1.  If we're out of bugs to fix, why not release?  Then folks like me can get 
> off the snapshot treadmill and we won't be annoyed by massive API delta until 
> we can do it all at once, which is (relatively) easy.
> 2.  If we're not out of bugs to fix, why not work on them, and then release, 
> and then come back to this?
> 3.  Since Swift 3 will have a stable ABI, why not ship both libdispatch2 and 
> libdispatch3 and let the programmer plan her own migration?  I'm not even 
> sure the stable ABI part is relevant, since Dispatch is almost entirely C.
> 
> All of these are saner alternatives to the proposal, and all of them achieve 
> the stated goal (e.g. we still end up with happy modern APIs).
> 
> I don't mean to pick on this proposal specifically, I agree with the need to 
> modernize the API surface area.  But if we continue to do breaking changes 
> first and releases later I'm concerned about where the early adopters will 
> get pushed to.
> 
> Drew
> ___
> 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] [swift-evolution-announce] [Review] SE-0088: Modernize libdispatch for Swift 3 naming conventions

[Xiaodi Wu via swift-evolution]

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 Linux, I'm running Swift 3 in production, essentially because
> Dispatch/Linux in 2.2 does not even exist.  On OSX/iOS, I compile the same
> codebase with Swift 2.2, because that's the version that's released, and
> using released software is a sane thing to do.
>
> This proposal places me in the uncomfortable situation of trying to
> somehow smooth out a truly MASSIVE API delta with #if.  And that's not
> going to happen.  Realistically, what I will do is create some kind of
> FrankenSwift that either backports the new API to Swift 3 or the old API to
> Swift 2.  And that is a ton of work, really stupid work, and I would
> infinitely prefer to spend that time doing something actually useful to the
> world.  To be clear, I don't fear migration; what I fear is the
> heisenmigration, where one of my platforms must migrate, and the other ones
> can't.
>
> More broadly, I am concerned about the direction the language is going
> where we do not even have working libraries yet and already we are doing
> sweeping API changes to them.  I suspect this is motivated by a
> fundamentally incorrect premise–the premise that because it's not released
> yet, we can get away with it.  When actually that's backwards: we can get
> away with breaking changes later, but if we do them now we will ruin
> everything.  Let me explain.
>
> Right now, Linux Swift programmers exist. And they need to be able to
> solve ordinary problems, like writing a string to a file, or spinning up a
> background thread.  And I do mean: sometime before Late 2016.  No amount of
> telling them "don't do that, it's not released" is going to stop this.  The
> only question is whether upstream is going to be the repo that solves their
> problem, or whether they go to solve the problem somewhere else.  Because
> when they go somewhere else, they invest there.
>
> Increasingly, because upstream is not interested in the problem, I am
> seeing Linux folk go solve the problem somewhere else.  Just counting the
> projects I'm personally aware of, there are 3 foundation alternatives and 1
> package manager alternative.  All because upstream has no sane path to e.g.
> reading a file on disk in the kind of timeframe working programmers
> actually need to do it in.
>
> What we *should* be doing is creating libraries that **work**, **releasing
> them**, and then we can do as much API Disneyland as we want without
> harassing the working programmer.
>
> 1.  If we're out of bugs to fix, why not release?  Then folks like me can
> get off the snapshot treadmill and we won't be annoyed by massive API delta
> until we can do it all at once, which is (relatively) easy.
> 2.  If we're not out of bugs to fix, why not work on them, and then
> release, and then come back to this?
> 3.  Since Swift 3 will have a stable ABI, why not ship both libdispatch2
> and libdispatch3 and let the programmer plan her own migration?  I'm not
> even sure the stable ABI part is relevant, since Dispatch is almost
> entirely C.
>
> All of these are saner alternatives to the proposal, and all of them
> achieve the stated goal (e.g. we still end up with happy modern APIs).
>
> I don't mean to pick on this proposal specifically, I agree with the need
> to modernize the API surface area.  But if we continue to do breaking
> changes first and releases later I'm concerned about where the early
> adopters will get pushed to.
>

FWIW, I believe the first Swift 3 preview branch is being created from
master tomorrow...


>
> Drew
>
> ___
> 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] [swift-evolution-announce] [Review] SE-0088: Modernize libdispatch for Swift 3 naming conventions

[Drew Crawford via swift-evolution]

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/iOS, I compile the same codebase with Swift 
2.2, because that's the version that's released, and using released software is 
a sane thing to do.

This proposal places me in the uncomfortable situation of trying to somehow 
smooth out a truly MASSIVE API delta with #if.  And that's not going to happen. 
 Realistically, what I will do is create some kind of FrankenSwift that either 
backports the new API to Swift 3 or the old API to Swift 2.  And that is a ton 
of work, really stupid work, and I would infinitely prefer to spend that time 
doing something actually useful to the world.  To be clear, I don't fear 
migration; what I fear is the heisenmigration, where one of my platforms must 
migrate, and the other ones can't.

More broadly, I am concerned about the direction the language is going where we 
do not even have working libraries yet and already we are doing sweeping API 
changes to them.  I suspect this is motivated by a fundamentally incorrect 
premise–the premise that because it's not released yet, we can get away with 
it.  When actually that's backwards: we can get away with breaking changes 
later, but if we do them now we will ruin everything.  Let me explain.

Right now, Linux Swift programmers exist. And they need to be able to solve 
ordinary problems, like writing a string to a file, or spinning up a background 
thread.  And I do mean: sometime before Late 2016.  No amount of telling them 
"don't do that, it's not released" is going to stop this.  The only question is 
whether upstream is going to be the repo that solves their problem, or whether 
they go to solve the problem somewhere else.  Because when they go somewhere 
else, they invest there.

Increasingly, because upstream is not interested in the problem, I am seeing 
Linux folk go solve the problem somewhere else.  Just counting the projects I'm 
personally aware of, there are 3 foundation alternatives and 1 package manager 
alternative.  All because upstream has no sane path to e.g. reading a file on 
disk in the kind of timeframe working programmers actually need to do it in.

What we *should* be doing is creating libraries that *work*, *releasing them*, 
and then we can do as much API Disneyland as we want without harassing the 
working programmer.

1.  If we're out of bugs to fix, why not release?  Then folks like me can get 
off the snapshot treadmill and we won't be annoyed by massive API delta until 
we can do it all at once, which is (relatively) easy.
2.  If we're not out of bugs to fix, why not work on them, and then release, 
and then come back to this?
3.  Since Swift 3 will have a stable ABI, why not ship both libdispatch2 and 
libdispatch3 and let the programmer plan her own migration?  I'm not even sure 
the stable ABI part is relevant, since Dispatch is almost entirely C.

All of these are saner alternatives to the proposal, and all of them achieve 
the stated goal (e.g. we still end up with happy modern APIs).

I don't mean to pick on this proposal specifically, I agree with the need to 
modernize the API surface area.  But if we continue to do breaking changes 
first and releases later I'm concerned about where the early adopters will get 
pushed to.

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