Re: [swift-evolution] Winding down the Swift 3 release

[L. Mihalkovic via swift-evolution]

> On May 24, 2016, at 1:21 AM, Chris Lattner via swift-evolution 
>  wrote:
> 
>> On May 23, 2016, at 2:17 AM, Jeremy Pereira via swift-evolution 
>>  wrote:
>> The collection model, API guidelines and standard library are actually 
>> irrelevant to the ABI. The standard library API and the Swift ABI are 
>> distinct orthogonal concepts.
> 
> I’m not sure what you’re saying.  If you change the API shipped by the 
> standard library, it obviously breaks anything that links to it.
> 
> The whole point of ABI stability is to not break apps built with old versions 
> of Swift compiler / standard library.
> 
> -Chris

I regularly read see how stability is a high prioriy goal going forward. But 
what I have not found yet what the plan is going to be to achieve it without 
stiffling the standard library? Are there constructs, or rules is place/planned 
that map how changes of kind A versus B level changes will be keeping/breaking 
compatibility? (I have not finished all the docs)




> ___
> 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] Winding down the Swift 3 release

[Chris Lattner via swift-evolution]

On May 23, 2016, at 2:17 AM, Jeremy Pereira via swift-evolution 
 wrote:
> The collection model, API guidelines and standard library are actually 
> irrelevant to the ABI. The standard library API and the Swift ABI are 
> distinct orthogonal concepts.

I’m not sure what you’re saying.  If you change the API shipped by the standard 
library, it obviously breaks anything that links to it.

The whole point of ABI stability is to not break apps built with old versions 
of Swift compiler / standard library.

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

Re: [swift-evolution] Winding down the Swift 3 release

[Jeremy Pereira via swift-evolution]

> On 19 May 2016, at 10:47, Brent Royal-Gordon  wrote:
> 
>> Is completing the generic system fundamental or not? I’d say it is vastly 
>> more fundamental than removing C style for loops, wouldn’t you?
> 
> Oh, come on. Removing the C-style for loop is not what took up time in this 
> release cycle. What took up time is the API guidelines, the new collection 
> model, and other standard library quality work—things which, in hindsight, 
> are prerequisites for binary compatibility anyway, because linking against a 
> different version doesn't count for much when all the names and calls have 
> changed anyway.

It is one of many things that have been done instead of concentrating on the 
goals as originally stated, five of which will not be met.

The collection model, API guidelines and standard library are actually 
irrelevant to the ABI. The standard library API and the Swift ABI are distinct 
orthogonal concepts.


> 
> -- 
> Brent Royal-Gordon
> Architechies
> 

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

Re: [swift-evolution] Winding down the Swift 3 release

[Zach Waldowski via swift-evolution]

On Thu, May 19, 2016, at 02:33 AM, Jeremy Pereira via swift-evolution
wrote:
> 
> > On 17 May 2016, at 23:45, Eric Wing via swift-evolution 
> >  wrote:
> > 
> > So I don’t mind (too much) if it takes longer to get a stable ABI. It
> > makes my life harder, but on the flip-side, I don’t want to be stuck
> > with yet another broken language and ABI. I want this done right
> > because it will be almost impossible to fix later.
> > 
> > Here’s a simple, yet tragic example: BOOL in Objective-C. We were
> > stuck with signed char instead of getting a real boolean. Back in 10.4
> > Tiger when the Intel migration was announced, I filed a bug report
> > reminding them that this was the chance to fix this. They didn’t fix
> > it, so we were stuck. Then I filed again in the 10.5 beta Leopard time
> > frame during the 64-bit transition, I filed again reminding them that
> > this should be fixed before the 64-bit ABI gets locked down. Again, it
> > wasn’t fixed so we were stuck. Then when the iOS SDK was going to
> > become public, I filed again. Still not fixed. Then armv7, still
> > nothing. Finally, for arm64, this was finally fixed. Too bad we’re
> > stuck on Mac with this probably forever.
> 
> Objective-C had a real boolean type as soon as the compiler was C99
> compatible and that’s when I started using it. BOOL is a typedef that is
> part of the Foundation/Cocoa API, not the Objective-C ABI.
> 
> 
> > 
> > Anyway, I don’t want to deal with another monstrous broken language.
> 
> Objective-C is not broken. It’s a fine language that has served the Apple
> development community for at least 15 years. It has quirks and problems
> but it is fit for purpose. The first binary I compiled in 64 bit mode
> will still run on my current OS X 10.11 laptop. Swift is already vastly
> nicer to program in but if I was a PHB trying to decide whether to invest
> in Swift skills for the future, things like “unstable ABI” and “source
> code breaking changes for Swift 3” would be colouring my opinion now and
> not in a good way.
> 
> I’d rather have a good language that is fit for production than one that
> is promised to be theoretically perfect at some as yet undefined future
> date.

Much like people are expressing relief that the compatibility goals for
the language are not being dictated by specific timelines, I would be
wholly concerned if any of Swift's goals were being defined by winning
the short-term favor of business people.

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

Sincerely,
  Zachary Waldowski
  z...@waldowski.me
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Winding down the Swift 3 release

[Brent Royal-Gordon via swift-evolution]

> Is completing the generic system fundamental or not? I’d say it is vastly 
> more fundamental than removing C style for loops, wouldn’t you?

Oh, come on. Removing the C-style for loop is not what took up time in this 
release cycle. What took up time is the API guidelines, the new collection 
model, and other standard library quality work—things which, in hindsight, are 
prerequisites for binary compatibility anyway, because linking against a 
different version doesn't count for much when all the names and calls have 
changed anyway.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] Winding down the Swift 3 release

[Jeremy Pereira via swift-evolution]

> On 17 May 2016, at 23:45, Eric Wing via swift-evolution 
>  wrote:
> 
> So I don’t mind (too much) if it takes longer to get a stable ABI. It
> makes my life harder, but on the flip-side, I don’t want to be stuck
> with yet another broken language and ABI. I want this done right
> because it will be almost impossible to fix later.
> 
> Here’s a simple, yet tragic example: BOOL in Objective-C. We were
> stuck with signed char instead of getting a real boolean. Back in 10.4
> Tiger when the Intel migration was announced, I filed a bug report
> reminding them that this was the chance to fix this. They didn’t fix
> it, so we were stuck. Then I filed again in the 10.5 beta Leopard time
> frame during the 64-bit transition, I filed again reminding them that
> this should be fixed before the 64-bit ABI gets locked down. Again, it
> wasn’t fixed so we were stuck. Then when the iOS SDK was going to
> become public, I filed again. Still not fixed. Then armv7, still
> nothing. Finally, for arm64, this was finally fixed. Too bad we’re
> stuck on Mac with this probably forever.

Objective-C had a real boolean type as soon as the compiler was C99 compatible 
and that’s when I started using it. BOOL is a typedef that is part of the 
Foundation/Cocoa API, not the Objective-C ABI.


> 
> Anyway, I don’t want to deal with another monstrous broken language.

Objective-C is not broken. It’s a fine language that has served the Apple 
development community for at least 15 years. It has quirks and problems but it 
is fit for purpose. The first binary I compiled in 64 bit mode will still run 
on my current OS X 10.11 laptop. Swift is already vastly nicer to program in 
but if I was a PHB trying to decide whether to invest in Swift skills for the 
future, things like “unstable ABI” and “source code breaking changes for Swift 
3” would be colouring my opinion now and not in a good way.

I’d rather have a good language that is fit for production than one that is 
promised to be theoretically perfect at some as yet undefined future date.


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

Re: [swift-evolution] Winding down the Swift 3 release

[Jeremy Pereira via swift-evolution]

> On 17 May 2016, at 14:38, Rod Brown  wrote:
> 
> While on the face of it, you are correct, the goals have changed 
> dramatically, I think you are being unfair.


The goals changed dramatically last week. It’s there in the git history. Last 
week was *after* the first developer preview of Swift 3.

I’m not being unfair, I’m being realistic. 

> 
> Swift 3 initial scope was determined prior to the input of the Swift 
> Evolution community, just as it was being Open Sourced. As we have explored 
> the language in many discussions, it has been clear there are other areas of 
> the language that needed clean and polish before a stable ABI can be 
> established.


I have no objection to having changed priorities, but these need to be 
communicated at the time the priorities change. When exactly was the stable ABI 
priority dropped? Was it last week, or was it months ago? Looking at the git 
history it was last week and the Swift community was not consulted in that 
change AFAIK. 

Nobody outside of the development team knew that all this debate about 
relatively minor language features was going to prevent us from meeting the 
goals for Swift 3. If we had known, maybe a lot of the issues that we did talk 
about would have been deferred instead of completing generics and a stable ABI. 
If somebody had said to you “we can make all these relatively minor changes to 
the language or we can complete generics, but not both” which would  you have 
chosen? 


> 
> It appears that this work is more involved than the Swift Team initially 
> envisioned. The fact they are open to changing timelines and ensuring we get 
> fundamentals of the language sorted is a testament to their commitment to the 
> quality of Swift as a whole.

Is completing the generic system fundamental or not? I’d say it is vastly more 
fundamental than removing C style for loops, wouldn’t you?



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

Re: [swift-evolution] Winding down the Swift 3 release

[Stephan Tolksdorf via swift-evolution]

Hi,

I'm curious, has the Swift team considered not having a public stable 
ABI for Swift at all, and instead only define some kind of versioned 
low-level bitcode for packaging purposes which then would be compiled 
and linked by a system/package repository/App Store service?


This would allow the ABI to evolve with the compiler and would provide 
more flexibility for e.g. the compilation of generic code and the 
implementation of shared libraries.


- Stephan

On 2016-05-16, Chris Lattner via swift-evolution wrote:

That said, it is also clear at this point that some of the loftier goals that 
we started out with aren’t going to fit into the release - including some of 
the most important generics features needed in order to lock down the ABI of 
the standard library. As such, the generics and ABI stability goals will roll 
into a future release of Swift, where I expect them to be the *highest* 
priority features to get done.

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

Re: [swift-evolution] Winding down the Swift 3 release

[Greg Parker via swift-evolution]

> On May 17, 2016, at 3:45 PM, Eric Wing via swift-evolution 
>  wrote:
> 
> So I don’t mind (too much) if it takes longer to get a stable ABI. It
> makes my life harder, but on the flip-side, I don’t want to be stuck
> with yet another broken language and ABI. I want this done right
> because it will be almost impossible to fix later.
> 
> Here’s a simple, yet tragic example: BOOL in Objective-C. We were
> stuck with signed char instead of getting a real boolean. Back in 10.4
> Tiger when the Intel migration was announced, I filed a bug report
> reminding them that this was the chance to fix this. They didn’t fix
> it, so we were stuck. Then I filed again in the 10.5 beta Leopard time
> frame during the 64-bit transition, I filed again reminding them that
> this should be fixed before the 64-bit ABI gets locked down. Again, it
> wasn’t fixed so we were stuck. Then when the iOS SDK was going to
> become public, I filed again. Still not fixed. Then armv7, still
> nothing. Finally, for arm64, this was finally fixed. Too bad we’re
> stuck on Mac with this probably forever.

We apologize for the inconvenience.

The OS X and iOS architecture transitions demonstrate the two fundamental laws 
of ABI changes:
1. Opportunities to break ABI compatibility are rare.
2. Any opportunity to break ABI compatibility will suffer from severe schedule 
pressure.

The Objective-C ABIs have many problems that would have been improved with more 
time.
* We tried to get a "modern" ABI into i386, but the schedule was too tight and 
we lost time with some initial design ideas that didn't pan out. x86_64 was 
also a tight schedule, but much of the work was already in place from the i386 
attempt so we were able to get it done.
* Fixing BOOL was repeatedly not quite high enough priority. 
* The 64-bit metadata structures have at least one field that is 64-bit by 
accident (protocol_list_t.count). There was miscommunication between the 
compiler and the runtime when the design was specified, and then it was never 
high enough priority to coordinate a fix later.
* armv7 uses setjmp-longjmp exceptions instead of "zero-cost" exceptions 
because that's what GCC's arm compiler used then and we didn't have time to 
change it.
* The very first iPhone did not use a "modern" ABI. We knew we could break ABI 
compatibility at any time before 3rd party apps were supported, so we punted 
ABI modernization until after 1.0.
* Non-fragile ivars on iPhone had a fragility bug in the compiler. (You don't 
see non-fragile ivars doing their thing until the *second* release, except for 
deliberate testing. We didn't test enough.) Luckily the bad case was narrow and 
the miscompiled code was detectable by inspecting binaries in the App Store, so 
we were able to ask all of the affected apps to recompile with a fixed compiler 
before the next iPhoneOS version shipped.

If we tried to rush Swift ABI stability out the door for Swift 3 we would 
certainly end up with deliberate or accidental flaws like the above. Being able 
to take the time to get it right is a rare luxury.


-- 
Greg Parker gpar...@apple.com  Runtime 
Wrangler


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

Re: [swift-evolution] Winding down the Swift 3 release

[Eric Wing via swift-evolution]

So I don’t mind (too much) if it takes longer to get a stable ABI. It
makes my life harder, but on the flip-side, I don’t want to be stuck
with yet another broken language and ABI. I want this done right
because it will be almost impossible to fix later.

Here’s a simple, yet tragic example: BOOL in Objective-C. We were
stuck with signed char instead of getting a real boolean. Back in 10.4
Tiger when the Intel migration was announced, I filed a bug report
reminding them that this was the chance to fix this. They didn’t fix
it, so we were stuck. Then I filed again in the 10.5 beta Leopard time
frame during the 64-bit transition, I filed again reminding them that
this should be fixed before the 64-bit ABI gets locked down. Again, it
wasn’t fixed so we were stuck. Then when the iOS SDK was going to
become public, I filed again. Still not fixed. Then armv7, still
nothing. Finally, for arm64, this was finally fixed. Too bad we’re
stuck on Mac with this probably forever.

Anyway, I don’t want to deal with another monstrous broken language.
We have enough of those already. I actually consider it a good sign
when languages remove features instead of add them even if it causes
some migration pain. And I appreciate caution about making sure things
are correct and good before locking down an ABI we’re probably going
to be stuck with for at least another decade.

I assume that Apple still understands the importance of ABI
compatibility due to the Mac heritage and now that iOS has enabled 3rd
party framework support. So I’m fairly confident they will eventually
nail down a stable ABI. I just don’t want the Swift team to forget
that a stable ABI is important for all the other platforms too (even
if those platforms are terrible at delivering this themselves).

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

Re: [swift-evolution] Winding down the Swift 3 release

[David Waite via swift-evolution]

With semantic versioning, the API changes would require the next version to be 
called 3.0. The challenge is to not attach stability/maturity ‘feelings’ to 
semantic version numbers.

I don’t think people should attach meaning to Swift being 3.0 any more than 
they do to Chrome being 50.0

If we insist 3.0 is not just a sign of an incompatible API but a sign of 
maturity, then we will have no releases until the “maturity” feature-set gets 
in. Which means we will lose a great deal of real world use and feedback into 
language design and evolution.

-DW

> On May 17, 2016, at 12:05 PM, Goffredo Marocchi via swift-evolution 
>  wrote:
> 
> I do agree with what you are saying, but in a way it seems to also be saying 
> that the version number set by Apple is a bit rushed. A language reaching 3.0 
> state and not having nailed down ABI stability sounds a lot different than 
> Swift 0.95 or Swift 1.5 being at the same state and I do not think it would 
> say anything bad about the language if it only hit 1.0 when it reaches ABI 
> stability. 
> 
> It would be sad if the argument were "people would not use Swift if it were 
> still v0.9" as it brings back memories of the KDE 4.0 jump (Swift is nowhere 
> near the unstable mess KDE 4.0 was, but they had that very same justification 
> for using the 4.0 version number).
> 
> Sent from my iPhone
> 
>> On 17 May 2016, at 14:38, Rod Brown  wrote:
>> 
>> While on the face of it, you are correct, the goals have changed 
>> dramatically, I think you are being unfair.
>> 
>> Swift 3 initial scope was determined prior to the input of the Swift 
>> Evolution community, just as it was being Open Sourced. As we have explored 
>> the language in many discussions, it has been clear there are other areas of 
>> the language that needed clean and polish before a stable ABI can be 
>> established.
>> 
>> It appears that this work is more involved than the Swift Team initially 
>> envisioned. The fact they are open to changing timelines and ensuring we get 
>> fundamentals of the language sorted is a testament to their commitment to 
>> the quality of Swift as a whole.
>> 
>> Looking at Swift 3 as compared to Swift 2, there are massive changes in the 
>> pipeline that both break source and change the language fundamentally. I 
>> think it's far too much to ask that they get this work done rushed, and also 
>> pile on ABI compatibility goals at the last minute. Do we really want to 
>> rush this and get it wrong?
>> 
>> I applaud the team in making a tough decision that these changes should come 
>> before we start working on the ABI.
>> 
>> - Rod
>> 
>>> On 17 May 2016, at 10:35 PM, Jeremy Pereira via swift-evolution 
>>>  wrote:
>>> 
>>> 
 On 16 May 2016, at 18:38, Goffredo Marocchi via swift-evolution 
  wrote:
 
 Quite sad we could not get into ABI stability for Swift 3... but are we 
 talking Swift 3.1 or 4.0?
>>> 
>>> 
>>> Disappointing is my first thought, in fact worrying. Two years after the 
>>> language was announced, the ABI is still not stable.
>>> 
>>> Of the original Swift 3 goals, it looks like many will not be met. There 
>>> were seven goals and only two are still in the Readme file[1]. On the 
>>> assumption that the other five were all dropped because they will not be 
>>> achieved in Swift 3, this looks like failure.
>>> 
>>> I’ve been following the evolution list on and off since it started and it 
>>> hasn’t felt like failure. In fact, it felt like important progress has been 
>>> made and the language will be hugely better for it, but I do hope that the 
>>> development team does take the opportunity to review the release in light 
>>> of the original goals to see if there are any opportunities to improve the 
>>> development process for the next release.
>>> 
>>> 
>>> [1] 
>>> https://github.com/apple/swift-evolution/blob/d6e62467b03435bdc4b3bd473c3dcffb9fdd6a71/README.md
>>>  compared to 
>>> https://github.com/apple/swift-evolution/blob/f11d2e970521f5df0f7510f89ee9c7decb3fa394/README.md
>>> 
>>> 
>>> 
 
 Sent from my iPhone
>>> 
>>> ___
>>> 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] Winding down the Swift 3 release

[Goffredo Marocchi via swift-evolution]

I do agree with what you are saying, but in a way it seems to also be saying 
that the version number set by Apple is a bit rushed. A language reaching 3.0 
state and not having nailed down ABI stability sounds a lot different than 
Swift 0.95 or Swift 1.5 being at the same state and I do not think it would say 
anything bad about the language if it only hit 1.0 when it reaches ABI 
stability. 

It would be sad if the argument were "people would not use Swift if it were 
still v0.9" as it brings back memories of the KDE 4.0 jump (Swift is nowhere 
near the unstable mess KDE 4.0 was, but they had that very same justification 
for using the 4.0 version number).

Sent from my iPhone

> On 17 May 2016, at 14:38, Rod Brown  wrote:
> 
> While on the face of it, you are correct, the goals have changed 
> dramatically, I think you are being unfair.
> 
> Swift 3 initial scope was determined prior to the input of the Swift 
> Evolution community, just as it was being Open Sourced. As we have explored 
> the language in many discussions, it has been clear there are other areas of 
> the language that needed clean and polish before a stable ABI can be 
> established.
> 
> It appears that this work is more involved than the Swift Team initially 
> envisioned. The fact they are open to changing timelines and ensuring we get 
> fundamentals of the language sorted is a testament to their commitment to the 
> quality of Swift as a whole.
> 
> Looking at Swift 3 as compared to Swift 2, there are massive changes in the 
> pipeline that both break source and change the language fundamentally. I 
> think it's far too much to ask that they get this work done rushed, and also 
> pile on ABI compatibility goals at the last minute. Do we really want to rush 
> this and get it wrong?
> 
> I applaud the team in making a tough decision that these changes should come 
> before we start working on the ABI.
> 
> - Rod
> 
>> On 17 May 2016, at 10:35 PM, Jeremy Pereira via swift-evolution 
>>  wrote:
>> 
>> 
>>> On 16 May 2016, at 18:38, Goffredo Marocchi via swift-evolution 
>>>  wrote:
>>> 
>>> Quite sad we could not get into ABI stability for Swift 3... but are we 
>>> talking Swift 3.1 or 4.0?
>> 
>> 
>> Disappointing is my first thought, in fact worrying. Two years after the 
>> language was announced, the ABI is still not stable.
>> 
>> Of the original Swift 3 goals, it looks like many will not be met. There 
>> were seven goals and only two are still in the Readme file[1]. On the 
>> assumption that the other five were all dropped because they will not be 
>> achieved in Swift 3, this looks like failure.
>> 
>> I’ve been following the evolution list on and off since it started and it 
>> hasn’t felt like failure. In fact, it felt like important progress has been 
>> made and the language will be hugely better for it, but I do hope that the 
>> development team does take the opportunity to review the release in light of 
>> the original goals to see if there are any opportunities to improve the 
>> development process for the next release.
>> 
>> 
>> [1] 
>> https://github.com/apple/swift-evolution/blob/d6e62467b03435bdc4b3bd473c3dcffb9fdd6a71/README.md
>>  compared to 
>> https://github.com/apple/swift-evolution/blob/f11d2e970521f5df0f7510f89ee9c7decb3fa394/README.md
>> 
>> 
>> 
>>> 
>>> Sent from my iPhone
>> 
>> ___
>> 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] Winding down the Swift 3 release

[Pierre Habouzit via swift-evolution]

> On May 17, 2016, at 5:35 AM, Jeremy Pereira via swift-evolution 
>  wrote:
> 
> 
>> On 16 May 2016, at 18:38, Goffredo Marocchi via swift-evolution 
>>  wrote:
>> 
>> Quite sad we could not get into ABI stability for Swift 3... but are we 
>> talking Swift 3.1 or 4.0?
> 
> 
> Disappointing is my first thought, in fact worrying. Two years after the 
> language was announced, the ABI is still not stable.
> 
> Of the original Swift 3 goals, it looks like many will not be met. There were 
> seven goals and only two are still in the Readme file[1]. On the assumption 
> that the other five were all dropped because they will not be achieved in 
> Swift 3, this looks like failure.
> 
> I’ve been following the evolution list on and off since it started and it 
> hasn’t felt like failure. In fact, it felt like important progress has been 
> made and the language will be hugely better for it, but I do hope that the 
> development team does take the opportunity to review the release in light of 
> the original goals to see if there are any opportunities to improve the 
> development process for the next release.

https://en.wikipedia.org/wiki/Hofstadter%27s_law

> [1] 
> https://github.com/apple/swift-evolution/blob/d6e62467b03435bdc4b3bd473c3dcffb9fdd6a71/README.md
>  compared to 
> https://github.com/apple/swift-evolution/blob/f11d2e970521f5df0f7510f89ee9c7decb3fa394/README.md


-Pierre

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

Re: [swift-evolution] Winding down the Swift 3 release

[Thorsten Seitz via swift-evolution]

+1

-Thorsten 

> Am 17.05.2016 um 15:38 schrieb Rod Brown via swift-evolution 
> :
> 
> While on the face of it, you are correct, the goals have changed 
> dramatically, I think you are being unfair.
> 
> Swift 3 initial scope was determined prior to the input of the Swift 
> Evolution community, just as it was being Open Sourced. As we have explored 
> the language in many discussions, it has been clear there are other areas of 
> the language that needed clean and polish before a stable ABI can be 
> established.
> 
> It appears that this work is more involved than the Swift Team initially 
> envisioned. The fact they are open to changing timelines and ensuring we get 
> fundamentals of the language sorted is a testament to their commitment to the 
> quality of Swift as a whole.
> 
> Looking at Swift 3 as compared to Swift 2, there are massive changes in the 
> pipeline that both break source and change the language fundamentally. I 
> think it's far too much to ask that they get this work done rushed, and also 
> pile on ABI compatibility goals at the last minute. Do we really want to rush 
> this and get it wrong?
> 
> I applaud the team in making a tough decision that these changes should come 
> before we start working on the ABI.
> 
> - Rod
> 
>> On 17 May 2016, at 10:35 PM, Jeremy Pereira via swift-evolution 
>>  wrote:
>> 
>> 
>>> On 16 May 2016, at 18:38, Goffredo Marocchi via swift-evolution 
>>>  wrote:
>>> 
>>> Quite sad we could not get into ABI stability for Swift 3... but are we 
>>> talking Swift 3.1 or 4.0?
>> 
>> 
>> Disappointing is my first thought, in fact worrying. Two years after the 
>> language was announced, the ABI is still not stable.
>> 
>> Of the original Swift 3 goals, it looks like many will not be met. There 
>> were seven goals and only two are still in the Readme file[1]. On the 
>> assumption that the other five were all dropped because they will not be 
>> achieved in Swift 3, this looks like failure.
>> 
>> I’ve been following the evolution list on and off since it started and it 
>> hasn’t felt like failure. In fact, it felt like important progress has been 
>> made and the language will be hugely better for it, but I do hope that the 
>> development team does take the opportunity to review the release in light of 
>> the original goals to see if there are any opportunities to improve the 
>> development process for the next release.
>> 
>> 
>> [1] 
>> https://github.com/apple/swift-evolution/blob/d6e62467b03435bdc4b3bd473c3dcffb9fdd6a71/README.md
>>  compared to 
>> https://github.com/apple/swift-evolution/blob/f11d2e970521f5df0f7510f89ee9c7decb3fa394/README.md
>> 
>> 
>> 
>>> 
>>> Sent from my iPhone
>> 
>> ___
>> 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] Winding down the Swift 3 release

[Rod Brown via swift-evolution]

While on the face of it, you are correct, the goals have changed dramatically, 
I think you are being unfair.

Swift 3 initial scope was determined prior to the input of the Swift Evolution 
community, just as it was being Open Sourced. As we have explored the language 
in many discussions, it has been clear there are other areas of the language 
that needed clean and polish before a stable ABI can be established.

It appears that this work is more involved than the Swift Team initially 
envisioned. The fact they are open to changing timelines and ensuring we get 
fundamentals of the language sorted is a testament to their commitment to the 
quality of Swift as a whole.

Looking at Swift 3 as compared to Swift 2, there are massive changes in the 
pipeline that both break source and change the language fundamentally. I think 
it's far too much to ask that they get this work done rushed, and also pile on 
ABI compatibility goals at the last minute. Do we really want to rush this and 
get it wrong?

I applaud the team in making a tough decision that these changes should come 
before we start working on the ABI.

- Rod

> On 17 May 2016, at 10:35 PM, Jeremy Pereira via swift-evolution 
>  wrote:
> 
> 
>> On 16 May 2016, at 18:38, Goffredo Marocchi via swift-evolution 
>>  wrote:
>> 
>> Quite sad we could not get into ABI stability for Swift 3... but are we 
>> talking Swift 3.1 or 4.0?
> 
> 
> Disappointing is my first thought, in fact worrying. Two years after the 
> language was announced, the ABI is still not stable.
> 
> Of the original Swift 3 goals, it looks like many will not be met. There were 
> seven goals and only two are still in the Readme file[1]. On the assumption 
> that the other five were all dropped because they will not be achieved in 
> Swift 3, this looks like failure.
> 
> I’ve been following the evolution list on and off since it started and it 
> hasn’t felt like failure. In fact, it felt like important progress has been 
> made and the language will be hugely better for it, but I do hope that the 
> development team does take the opportunity to review the release in light of 
> the original goals to see if there are any opportunities to improve the 
> development process for the next release.
> 
> 
> [1] 
> https://github.com/apple/swift-evolution/blob/d6e62467b03435bdc4b3bd473c3dcffb9fdd6a71/README.md
>  compared to 
> https://github.com/apple/swift-evolution/blob/f11d2e970521f5df0f7510f89ee9c7decb3fa394/README.md
> 
> 
> 
>> 
>> Sent from my iPhone
> 
> ___
> 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] Winding down the Swift 3 release

[Jeremy Pereira via swift-evolution]

> On 16 May 2016, at 18:38, Goffredo Marocchi via swift-evolution 
>  wrote:
> 
> Quite sad we could not get into ABI stability for Swift 3... but are we 
> talking Swift 3.1 or 4.0?


Disappointing is my first thought, in fact worrying. Two years after the 
language was announced, the ABI is still not stable.

Of the original Swift 3 goals, it looks like many will not be met. There were 
seven goals and only two are still in the Readme file[1]. On the assumption 
that the other five were all dropped because they will not be achieved in Swift 
3, this looks like failure.

I’ve been following the evolution list on and off since it started and it 
hasn’t felt like failure. In fact, it felt like important progress has been 
made and the language will be hugely better for it, but I do hope that the 
development team does take the opportunity to review the release in light of 
the original goals to see if there are any opportunities to improve the 
development process for the next release.


[1] 
https://github.com/apple/swift-evolution/blob/d6e62467b03435bdc4b3bd473c3dcffb9fdd6a71/README.md
 compared to 
https://github.com/apple/swift-evolution/blob/f11d2e970521f5df0f7510f89ee9c7decb3fa394/README.md



> 
> Sent from my iPhone
> 

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

Re: [swift-evolution] Winding down the Swift 3 release

[Leonardo Pessoa via swift-evolution]

I'm speaking for myself here but I'm already working independent projects in 
Linux here. The only missing feature to my current needs it's the 
implementation of NSBundle methods like load(). Any idea when we'll get those 
implemented?

- Leonardo

-Original Message-
From: "Chris Lattner via swift-evolution" <swift-evolution@swift.org>
Sent: ‎16/‎05/‎2016 06:07 PM
To: "Tim Hawkins" <tim.thawk...@gmail.com>
Cc: "Tino Heth via swift-evolution" <swift-evolution@swift.org>
Subject: Re: [swift-evolution] Winding down the Swift 3 release



On May 16, 2016, at 11:33 AM, Tim Hawkins <tim.thawk...@gmail.com> wrote:


At what point would you consider the Linux product to be viable for production 
server side application development. Do you think that goal has been achieved 
in swift 3.0. Or is it going to have to wait for the ABI lock down.  
I'm not an expert in the Linux communities needs and desires.  That said, from 
what I understand, they don’t care at all about ABI stability, since everything 
is typically built from source.


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

Re: [swift-evolution] Winding down the Swift 3 release

[Eric Wing via swift-evolution]

On 5/16/16, Chris Lattner  wrote:
> On May 16, 2016, at 2:27 PM, Eric Wing via swift-evolution
>  wrote:
>>> I'm not an expert in the Linux communities needs and desires.  That
>>> said,
>>> from what I understand, they don’t care at all about ABI stability,
>>> since
>>> everything is typically built from source.
>>
>> Not exactly true. (I care.)
>>
>> Video games (e.g. Steam/Linux) care deeply about ABI stability. And
>> Android cares deeply about ABI stability. Also, kind of emergent
>> behavior, Raspberry Pi Raspbian has kind of built a platform that
>> happens to have some ABI stability for now.
>
> Great to know, and good point.  From that perspective, a Steam/Linux project
> would be in the same category as an iOS or Mac app: ABI stability doesn’t
> matter, so long as you include a copy of the swift standard library along
> with the steam app itself.  I know nothing about Steam, but it seems likely
> that this would have been a requirement anyway, because you can’t count on
> the standard library already existing.
>

Yes. I actually filed some bug reports a few weeks ago for
thoughts/concerns/issues related to this.

> ABI stability starts to matter when you’re interested in combining
> precompiled libraries built by different parties, which are only distributed
> in binary form.
>

That is what I’m working on. I also care about Mac and iOS.

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

Re: [swift-evolution] Winding down the Swift 3 release

[Chris Lattner via swift-evolution]

On May 16, 2016, at 9:03 PM, Haris Amin  wrote:
> Hey Chris and team,
> 
> This is great news. Any news on when/if libdispatch linux compatibility will 
> ship with Swift 3?

Hi Haris,

That is still the goal - I know that many folks are intensely interested in 
making this happen, and are contributing a lot of code (maybe one of them can 
comment?).  OTOH, while it looks promising, it still isn’t quite done.  :-)

-Chris


> 
> Thanks again.
> 
> Haris
> > Hi Everyone,
> > 
> > As we get deeper into the Swift 3 release cycle, we’re beginning to have a 
> > more precise understanding about what the release will shape up to be. Ted 
> > posted details of the Swift 3 release process last week 
> > (https://swift.org/blog/swift-3-0-release-process/ 
> > ) and I just updated the 
> > main swift-evolution README.md file 
> > (https://github.com/apple/swift-evolution 
> > ) with some updated details about 
> > the goals of Swift 3.
> > 
> > This release is shaping up to be a really phenomenal release that will 
> > redefine the feel of Swift and make a major leap towards maturing the Swift 
> > language and development experience. We have had a focus on getting to 
> > source stability, with the forward-looking goal of making Swift 4 as source 
> > compatible with Swift 3 as we can reasonably accomplish. It tackled API 
> > naming head on (which is one of the hardest problems in computer science 
> > [1]), made major improvements to the consistency and feel of the language, 
> > and has several nice across the board additions.
> > 
> > That said, it is also clear at this point that some of the loftier goals 
> > that we started out with aren’t going to fit into the release - including 
> > some of the most important generics features needed in order to lock down 
> > the ABI of the standard library. As such, the generics and ABI stability 
> > goals will roll into a future release of Swift, where I expect them to be 
> > the *highest* priority features to get done.
> > 
> > I expect discussion and planning for Swift 3.x and Swift 4 to start 
> > sometime around August of this year. Until then, it is very important that 
> > we as a community stay focused on the goals of Swift 3: I’d really prefer 
> > us all to resist the urge to discuss major blue sky features for future 
> > releases. We would also like to put a significant amount of effort into bug 
> > fixing and quality refinements as well, which means that the core team will 
> > be proactively deferring evolution proposals to later releases that don’t 
> > align with the Swift 3 goals, especially those that are strictly additive.
> > 
> > Thank you for all of the amazing community that has developed on this list, 
> > it is great to work with you all! Let us know if you have any questions,
> > 
> > -Chris
> > 
> > [1] It is well known that the two hard problems in Computer Science are 
> > naming, cache invalidation, and off-by-one errors.
> > 
> > 
> >

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

Re: [swift-evolution] Winding down the Swift 3 release

[Chris Lattner via swift-evolution]

On May 16, 2016, at 2:27 PM, Eric Wing via swift-evolution 
 wrote:
>> I'm not an expert in the Linux communities needs and desires.  That said,
>> from what I understand, they don’t care at all about ABI stability, since
>> everything is typically built from source.
> 
> Not exactly true. (I care.)
> 
> Video games (e.g. Steam/Linux) care deeply about ABI stability. And
> Android cares deeply about ABI stability. Also, kind of emergent
> behavior, Raspberry Pi Raspbian has kind of built a platform that
> happens to have some ABI stability for now.

Great to know, and good point.  From that perspective, a Steam/Linux project 
would be in the same category as an iOS or Mac app: ABI stability doesn’t 
matter, so long as you include a copy of the swift standard library along with 
the steam app itself.  I know nothing about Steam, but it seems likely that 
this would have been a requirement anyway, because you can’t count on the 
standard library already existing.

ABI stability starts to matter when you’re interested in combining precompiled 
libraries built by different parties, which are only distributed in binary form.

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

Re: [swift-evolution] Winding down the Swift 3 release

[John McCall via swift-evolution]

> On May 16, 2016, at 2:06 PM, Chris Lattner via swift-evolution 
>  wrote:
>> On May 16, 2016, at 11:33 AM, Tim Hawkins > > wrote:
>> 
>> At what point would you consider the Linux product to be viable for 
>> production server side application development. Do you think that goal has 
>> been achieved in swift 3.0. Or is it going to have to wait for the ABI lock 
>> down. 
>> 
> I'm not an expert in the Linux communities needs and desires.  That said, 
> from what I understand, they don’t care at all about ABI stability, since 
> everything is typically built from source.

I think it would be more appropriate to say that the server development 
community generally doesn't care deeply about ABI stability (although even 
there I'm sure there are exceptions).  There are a lot of client-side efforts 
that have very different requirements from that, though.

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

Re: [swift-evolution] Winding down the Swift 3 release

[Charles Srstka via swift-evolution]

> On May 16, 2016, at 4:27 PM, Eric Wing via swift-evolution 
>  wrote:
> 
>> I'm not an expert in the Linux communities needs and desires.  That said,
>> from what I understand, they don’t care at all about ABI stability, since
>> everything is typically built from source.
>> 
>> -Chris
>> 
>> 
> 
> Not exactly true. (I care.)
> 
> Video games (e.g. Steam/Linux) care deeply about ABI stability. And
> Android cares deeply about ABI stability. Also, kind of emergent
> behavior, Raspberry Pi Raspbian has kind of built a platform that
> happens to have some ABI stability for now.
> 
> Thanks,
> Eric

ABI stability is also central to eventually removing the need to always ship 
the runtime along with our binaries.

Charles

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

Re: [swift-evolution] Winding down the Swift 3 release

[Eric Wing via swift-evolution]

> I'm not an expert in the Linux communities needs and desires.  That said,
> from what I understand, they don’t care at all about ABI stability, since
> everything is typically built from source.
>
> -Chris
>
>

Not exactly true. (I care.)

Video games (e.g. Steam/Linux) care deeply about ABI stability. And
Android cares deeply about ABI stability. Also, kind of emergent
behavior, Raspberry Pi Raspbian has kind of built a platform that
happens to have some ABI stability for now.

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

Re: [swift-evolution] Winding down the Swift 3 release

[Chris Lattner via swift-evolution]

On May 16, 2016, at 12:29 PM, Dan Stenmark  wrote:
> With the generics and ABI stability goals getting pushed out to a future 
> release, how does that affect the plans for Swift concurrency features?  Will 
> the topic still be explored in the Swift 4 timeframe, or do you expect that 
> discussion be deferred to 5 or beyond?

I expect us to discuss what goes into post-Swift-3.0 release in ~August this 
year.  I’m sure that many folks will be interested in this and many other 
topics.

-Chris

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

Re: [swift-evolution] Winding down the Swift 3 release

[Chris Lattner via swift-evolution]

> On May 16, 2016, at 11:53 AM, Ryan Lovelett  
> wrote:
> 
> On Mon, May 16, 2016, at 11:18 AM, Chris Lattner via swift-evolution
> wrote:
>> Hi Everyone,
>> 
>> As we get deeper into the Swift 3 release cycle, we’re beginning to have
>> a more precise understanding about what the release will shape up to be. 
>> Ted posted details of the Swift 3 release process last week
>> (https://swift.org/blog/swift-3-0-release-process/) and I just updated
>> the main swift-evolution README.md file
>> (https://github.com/apple/swift-evolution) with some updated details
>> about the goals of Swift 3.
> 
> I noticed this comment on Hacker News:
> https://news.ycombinator.com/item?id=11708052
> 
> The comment brought up a question about the "Portability" section
> disappearing from the README. Until reading that comment I had not
> noticed the removal of the goal. But upon examination I would like to
> know what the implication of that removal is.
> 
> Would you mind expanding on the implications of that section
> disappearing? Just an accidental omission? Is portability now considered
> done/achieved? Or are the core team members throwing in the towel on
> that goal? (Perhaps it is some variation on those themes or something
> completely different)

Portability is still a strong goal, I will add it back, thank you for raising 
this!

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

Re: [swift-evolution] Winding down the Swift 3 release

[Chris Lattner via swift-evolution]

> On May 16, 2016, at 11:33 AM, Tim Hawkins  wrote:
> 
> At what point would you consider the Linux product to be viable for 
> production server side application development. Do you think that goal has 
> been achieved in swift 3.0. Or is it going to have to wait for the ABI lock 
> down. 
> 
I'm not an expert in the Linux communities needs and desires.  That said, from 
what I understand, they don’t care at all about ABI stability, since everything 
is typically built from source.

-Chris

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

Re: [swift-evolution] Winding down the Swift 3 release

[Dan Stenmark via swift-evolution]

With the generics and ABI stability goals getting pushed out to a future 
release, how does that affect the plans for Swift concurrency features?  Will 
the topic still be explored in the Swift 4 timeframe, or do you expect that 
discussion be deferred to 5 or beyond?

Dan

> On May 16, 2016, at 8:18 AM, Chris Lattner via swift-evolution 
>  wrote:
> 
> Hi Everyone,
> 
> As we get deeper into the Swift 3 release cycle, we’re beginning to have a 
> more precise understanding about what the release will shape up to be.  Ted 
> posted details of the Swift 3 release process last week 
> (https://swift.org/blog/swift-3-0-release-process/) and I just updated the 
> main swift-evolution README.md file 
> (https://github.com/apple/swift-evolution) with some updated details about 
> the goals of Swift 3.
> 
> This release is shaping up to be a really phenomenal release that will 
> redefine the feel of Swift and make a major leap towards maturing the Swift 
> language and development experience.  We have had a focus on getting to 
> source stability, with the forward-looking goal of making Swift 4 as source 
> compatible with Swift 3 as we can reasonably accomplish.  It tackled API 
> naming head on (which is one of the hardest problems in computer science 
> [1]), made major improvements to the consistency and feel of the language, 
> and has several nice across the board additions.
> 
> That said, it is also clear at this point that some of the loftier goals that 
> we started out with aren’t going to fit into the release - including some of 
> the most important generics features needed in order to lock down the ABI of 
> the standard library. As such, the generics and ABI stability goals will roll 
> into a future release of Swift, where I expect them to be the *highest* 
> priority features to get done.
> 
> I expect discussion and planning for Swift 3.x and Swift 4 to start sometime 
> around August of this year.  Until then, it is very important that we as a 
> community stay focused on the goals of Swift 3: I’d really prefer us all to 
> resist the urge to discuss major blue sky features for future releases.  We 
> would also like to put a significant amount of effort into bug fixing and 
> quality refinements as well, which means that the core team will be 
> proactively deferring evolution proposals to later releases that don’t align 
> with the Swift 3 goals, especially those that are strictly additive.
> 
> Thank you for all of the amazing community that has developed on this list, 
> it is great to work with you all!  Let us know if you have any questions,
> 
> -Chris
> 
> [1] It is well known that the two hard problems in Computer Science are 
> naming, cache invalidation, and off-by-one errors.
> ___
> 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] Winding down the Swift 3 release

[Ryan Lovelett via swift-evolution]

On Mon, May 16, 2016, at 11:18 AM, Chris Lattner via swift-evolution
wrote:
> Hi Everyone,
> 
> As we get deeper into the Swift 3 release cycle, we’re beginning to have
> a more precise understanding about what the release will shape up to be. 
> Ted posted details of the Swift 3 release process last week
> (https://swift.org/blog/swift-3-0-release-process/) and I just updated
> the main swift-evolution README.md file
> (https://github.com/apple/swift-evolution) with some updated details
> about the goals of Swift 3.

I noticed this comment on Hacker News:
https://news.ycombinator.com/item?id=11708052

The comment brought up a question about the "Portability" section
disappearing from the README. Until reading that comment I had not
noticed the removal of the goal. But upon examination I would like to
know what the implication of that removal is.

Would you mind expanding on the implications of that section
disappearing? Just an accidental omission? Is portability now considered
done/achieved? Or are the core team members throwing in the towel on
that goal? (Perhaps it is some variation on those themes or something
completely different)

> 
> This release is shaping up to be a really phenomenal release that will
> redefine the feel of Swift and make a major leap towards maturing the
> Swift language and development experience.  We have had a focus on
> getting to source stability, with the forward-looking goal of making
> Swift 4 as source compatible with Swift 3 as we can reasonably
> accomplish.  It tackled API naming head on (which is one of the hardest
> problems in computer science [1]), made major improvements to the
> consistency and feel of the language, and has several nice across the
> board additions.
> 
> That said, it is also clear at this point that some of the loftier goals
> that we started out with aren’t going to fit into the release - including
> some of the most important generics features needed in order to lock down
> the ABI of the standard library. As such, the generics and ABI stability
> goals will roll into a future release of Swift, where I expect them to be
> the *highest* priority features to get done.
> 
> I expect discussion and planning for Swift 3.x and Swift 4 to start
> sometime around August of this year.  Until then, it is very important
> that we as a community stay focused on the goals of Swift 3: I’d really
> prefer us all to resist the urge to discuss major blue sky features for
> future releases.  We would also like to put a significant amount of
> effort into bug fixing and quality refinements as well, which means that
> the core team will be proactively deferring evolution proposals to later
> releases that don’t align with the Swift 3 goals, especially those that
> are strictly additive.
> 
> Thank you for all of the amazing community that has developed on this
> list, it is great to work with you all!  Let us know if you have any
> questions,
> 
> -Chris
> 
> [1] It is well known that the two hard problems in Computer Science are
> naming, cache invalidation, and off-by-one errors.
> ___
> 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] Winding down the Swift 3 release

[Tim Hawkins via swift-evolution]

At what point would you consider the Linux product to be viable for
production server side application development. Do you think that goal has
been achieved in swift 3.0. Or is it going to have to wait for the ABI lock
down.

I'm weighting the wisdom of possibly using Swift on linux for
microservices, we are comming from a modernPHP and OOP environment, and
many of the alternatives such as go and rust have higher impedance
mismatches than swift,  given the skills I have available in the
organisation.

I'm interested in cross platform app development down the line, but for
now, I'm only really interested in building out APIs with it.
On 17 May 2016 02:14, "Chris Lattner via swift-evolution" <
swift-evolution@swift.org> wrote:

> On May 16, 2016, at 10:38 AM, Goffredo Marocchi  wrote:
> > Quite sad we could not get into ABI stability for Swift 3... but are we
> talking Swift 3.1 or 4.0?
>
> We’ll start discussing post-3.0 releases in August.  Until Swift 3 is
> really wound down, it is almost impossible to make forward looking plans.
>
> -Chris
>
> >
> > Sent from my iPhone
> >
> >> On 16 May 2016, at 17:43, Chris Lattner via swift-evolution <
> swift-evolution@swift.org> wrote:
> >>
> >>
> >>> On May 16, 2016, at 9:29 AM, David Sweeris 
> wrote:
> >>>
> >>>
>  On May 16, 2016, at 10:18 AM, Chris Lattner via swift-evolution <
> swift-evolution@swift.org> wrote:
> 
>  That said, it is also clear at this point that some of the loftier
> goals that we started out with aren’t going to fit into the release -
> including some of the most important generics features needed in order to
> lock down the ABI of the standard library. As such, the generics and ABI
> stability goals will roll into a future release of Swift, where I expect
> them to be the *highest* priority features to get done.
> >>>
> >>> Oh, good! I was getting worried about that. Are there any particular
> topics that we should drop or discuss?
> >>
> >> The highest priority to me is to get the “little syntactic stuff” done
> that we want to nail down because it affects source stability.  A recent
> thing that came up was @noescape -> @nonescaping and whether to make it the
> default, for example.
> >>
> >> As for dropping, it is pretty clear that we are out of time for
> large-scope additions.
> >>
> >> -Chris
> >> ___
> >> 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] Winding down the Swift 3 release

[Chris Lattner via swift-evolution]

On May 16, 2016, at 10:38 AM, Goffredo Marocchi  wrote:
> Quite sad we could not get into ABI stability for Swift 3... but are we 
> talking Swift 3.1 or 4.0?

We’ll start discussing post-3.0 releases in August.  Until Swift 3 is really 
wound down, it is almost impossible to make forward looking plans.

-Chris

> 
> Sent from my iPhone
> 
>> On 16 May 2016, at 17:43, Chris Lattner via swift-evolution 
>>  wrote:
>> 
>> 
>>> On May 16, 2016, at 9:29 AM, David Sweeris  wrote:
>>> 
>>> 
 On May 16, 2016, at 10:18 AM, Chris Lattner via swift-evolution 
  wrote:
 
 That said, it is also clear at this point that some of the loftier goals 
 that we started out with aren’t going to fit into the release - including 
 some of the most important generics features needed in order to lock down 
 the ABI of the standard library. As such, the generics and ABI stability 
 goals will roll into a future release of Swift, where I expect them to be 
 the *highest* priority features to get done.
>>> 
>>> Oh, good! I was getting worried about that. Are there any particular topics 
>>> that we should drop or discuss?
>> 
>> The highest priority to me is to get the “little syntactic stuff” done that 
>> we want to nail down because it affects source stability.  A recent thing 
>> that came up was @noescape -> @nonescaping and whether to make it the 
>> default, for example.
>> 
>> As for dropping, it is pretty clear that we are out of time for large-scope 
>> additions.
>> 
>> -Chris
>> ___
>> 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] Winding down the Swift 3 release

[Goffredo Marocchi via swift-evolution]

Quite sad we could not get into ABI stability for Swift 3... but are we talking 
Swift 3.1 or 4.0?

Sent from my iPhone

> On 16 May 2016, at 17:43, Chris Lattner via swift-evolution 
>  wrote:
> 
> 
>> On May 16, 2016, at 9:29 AM, David Sweeris  wrote:
>> 
>> 
>>> On May 16, 2016, at 10:18 AM, Chris Lattner via swift-evolution 
>>>  wrote:
>>> 
>>> That said, it is also clear at this point that some of the loftier goals 
>>> that we started out with aren’t going to fit into the release - including 
>>> some of the most important generics features needed in order to lock down 
>>> the ABI of the standard library. As such, the generics and ABI stability 
>>> goals will roll into a future release of Swift, where I expect them to be 
>>> the *highest* priority features to get done.
>> 
>> Oh, good! I was getting worried about that. Are there any particular topics 
>> that we should drop or discuss?
> 
> The highest priority to me is to get the “little syntactic stuff” done that 
> we want to nail down because it affects source stability.  A recent thing 
> that came up was @noescape -> @nonescaping and whether to make it the 
> default, for example.
> 
> As for dropping, it is pretty clear that we are out of time for large-scope 
> additions.
> 
> -Chris
> ___
> 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] Winding down the Swift 3 release

[Chris Lattner via swift-evolution]

> On May 16, 2016, at 9:29 AM, David Sweeris  wrote:
> 
> 
>> On May 16, 2016, at 10:18 AM, Chris Lattner via swift-evolution 
>>  wrote:
>> 
>> That said, it is also clear at this point that some of the loftier goals 
>> that we started out with aren’t going to fit into the release - including 
>> some of the most important generics features needed in order to lock down 
>> the ABI of the standard library. As such, the generics and ABI stability 
>> goals will roll into a future release of Swift, where I expect them to be 
>> the *highest* priority features to get done.
> 
> Oh, good! I was getting worried about that. Are there any particular topics 
> that we should drop or discuss?

The highest priority to me is to get the “little syntactic stuff” done that we 
want to nail down because it affects source stability.  A recent thing that 
came up was @noescape -> @nonescaping and whether to make it the default, for 
example.

As for dropping, it is pretty clear that we are out of time for large-scope 
additions.

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

Re: [swift-evolution] Winding down the Swift 3 release

[David Sweeris via swift-evolution]

> On May 16, 2016, at 10:18 AM, Chris Lattner via swift-evolution 
>  wrote:
> 
> That said, it is also clear at this point that some of the loftier goals that 
> we started out with aren’t going to fit into the release - including some of 
> the most important generics features needed in order to lock down the ABI of 
> the standard library. As such, the generics and ABI stability goals will roll 
> into a future release of Swift, where I expect them to be the *highest* 
> priority features to get done.

Oh, good! I was getting worried about that. Are there any particular topics 
that we should drop or discuss?

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