Re: [swift-evolution] [swift-evolution-announce] Swift 5: start your engines

[John McCall via swift-evolution]

> On Aug 9, 2017, at 8:52 PM, Howard Lovatt via swift-evolution 
>  wrote:
> I am not against these changes, of requiring an implementation, but I am a 
> little nervous. Let me expand.
> 
> I was involved in the Java Coin initiative for community driven changes to 
> Java 7. In that process the implementation barrier was set very high and it 
> effectively meant that only changes from Sun got through, a number of people 
> put considerable effort in only for the proposals to be rejected. I felt the 
> process was in the end a little disingenuous and I think that view was held 
> by many, perhaps tellingly the process has never run again for subsequent 
> Java versions.
> 
> So my cautionary note is that this requirement of implementation requires 
> careful stewardship and in particular there needs to be some means of getting 
> 'in principle' approval before the implementation stage. If done correctly it 
> could work very well.

This seems very sensible to me.  Certainly we would want some way of flushing 
out "in principle" concerns before too much implementation time gets spent.

John.

> 
>   -- Howard.
> 
> On 9 August 2017 at 02:23, Ted Kremenek  > wrote:
> Hi everyone,
> 
> The proposal phase for Swift 4 is now officially over, and the release is now 
> in endgame engineering convergence for an expected release later this year.  
> Swift 4 has turned out to be one of the highest quality, well-rounded 
> releases of Swift, and I am grateful to everyone in the community who made 
> this release come together!
> 
> Now it is time to turn our attention to Swift 5.  I have just posted updates 
> to the README.md file on the swift-evolution repository, which outlines the 
> core themes and focus areas for Swift 5:
> 
>   https://github.com/apple/swift-evolution 
> 
> 
> and a more persistent URL (invariant to future README.md changes):
> 
>   
> https://github.com/apple/swift-evolution/blob/9cc90f33b6659adeaf92355c359e34e6fed73254/README.md
>  
> 
> 
> I am not going to repeat all of that information here, but I wanted to 
> highlight a few important things.
> 
> ## ABI Stability
> 
> First, ABI stability is the center focus of Swift 5 — and we will pivot much 
> of our prioritization of efforts for Swift 5 around it.  With Swift 4, ABI 
> stability was a strong goal.  In Swift 5, it is a *requirement* of the 
> release.  Whatever ABI we have at the end of Swift 5 is the ABI that we will 
> have.  ABI stability is an important inflection point for the maturity of the 
> language, and it cannot be delayed any longer.
> 
> Please note that there is a difference between ABI stability and module 
> stability.   If you are not aware of the difference — which is rather 
> important — please read the first few paragraphs of the ABI stability 
> manifesto:
> 
>   https://github.com/apple/swift/blob/master/docs/ABIStabilityManifesto.md 
> 
> 
> Module stability is a stretch goal for Swift 5, but even without module 
> stability we can still achieve the primary value of ABI stability.
> 
> ##  Other focus areas (including laying the groundwork for concurrency)
> 
> There are several other areas mentioned for Swift 5 which I won’t repeat 
> here, but there is a general theme of refining and broadening out the core 
> ergonomics of the language and standard library.
> 
> One of those that I wanted to highlight is laying the groundwork for 
> concurrency.  It is a non-goal of Swift 5 to roll out a full new concurrency 
> model.  That is simply too large an effort to do alongside ABI stability.  
> However, it is important that we start making progress on discussing the 
> directions for concurrency and laying some of the groundwork.  This may take 
> the form of specific enhancements to the language that get implemented, 
> depending on where the discussions for concurrency lead and how they align 
> with the priorities for delivering ABI stability in Swift 5.
> 
> ## Changes to the language evolution process
> 
> Last, I want to highlight important changes to the evolution process:
> 
>   https://github.com/apple/swift-evolution 
> #evolution-process-for-swift-5 
> 
> 
> With Swift 4, the release period was divided up into “stage 1” and “stage 2” 
> for setting guidelines for the kind of evolution proposals that were in scope 
> for the release.  This was needed to establish focus — especially after the 
> churn we saw during Swift 3 — on some core themes that were aligned with 
> converging the language towards source & ABI stability.  One downside is that 
> “stage 2” opened up discussion for 

Re: [swift-evolution] [swift-evolution-announce] Swift 5: start your engines

[Howard Lovatt via swift-evolution]

I am not against these changes, of requiring an implementation, but I am a
little nervous. Let me expand.

I was involved in the Java Coin initiative for community driven changes to
Java 7. In that process the implementation barrier was set very high and it
effectively meant that only changes from Sun got through, a number of
people put considerable effort in only for the proposals to be rejected. I
felt the process was in the end a little disingenuous and I think that view
was held by many, perhaps tellingly the process has never run again for
subsequent Java versions.

So my cautionary note is that this requirement of implementation requires
careful stewardship and in particular there needs to be some means of
getting 'in principle' approval before the implementation stage. If done
correctly it could work very well.

  -- Howard.

On 9 August 2017 at 02:23, Ted Kremenek  wrote:

> Hi everyone,
>
> The proposal phase for Swift 4 is now officially over, and the release is
> now in endgame engineering convergence for an expected release later this
> year.  Swift 4 has turned out to be one of the highest quality,
> well-rounded releases of Swift, and I am grateful to everyone in the
> community who made this release come together!
>
> Now it is time to turn our attention to Swift 5.  I have just posted
> updates to the README.md file on the swift-evolution repository, which
> outlines the core themes and focus areas for Swift 5:
>
>   https://github.com/apple/swift-evolution
>
> and a more persistent URL (invariant to future README.md changes):
>
>   https://github.com/apple/swift-evolution/blob/
> 9cc90f33b6659adeaf92355c359e34e6fed73254/README.md
>
> I am not going to repeat all of that information here, but I wanted to
> highlight a few important things.
>
> ## ABI Stability
>
> First, ABI stability is the center focus of Swift 5 — and we will pivot
> much of our prioritization of efforts for Swift 5 around it.  With Swift 4,
> ABI stability was a strong goal.  In Swift 5, it is a *requirement* of the
> release.  Whatever ABI we have at the end of Swift 5 is the ABI that we
> will have.  ABI stability is an important inflection point for the maturity
> of the language, and it cannot be delayed any longer.
>
> Please note that there is a difference between ABI stability and module
> stability.   If you are not aware of the difference — which is rather
> important — please read the first few paragraphs of the ABI stability
> manifesto:
>
>   https://github.com/apple/swift/blob/master/docs/ABIStabilityManifesto.md
>
> Module stability is a stretch goal for Swift 5, but even without module
> stability we can still achieve the primary value of ABI stability.
>
> ##  Other focus areas (including laying the groundwork for concurrency)
>
> There are several other areas mentioned for Swift 5 which I won’t repeat
> here, but there is a general theme of refining and broadening out the core
> ergonomics of the language and standard library.
>
> One of those that I wanted to highlight is laying the groundwork for
> concurrency.  It is a non-goal of Swift 5 to roll out a full new
> concurrency model.  That is simply too large an effort to do alongside ABI
> stability.  However, it is important that we start making progress on
> discussing the directions for concurrency and laying some of the
> groundwork.  This may take the form of specific enhancements to the
> language that get implemented, depending on where the discussions for
> concurrency lead and how they align with the priorities for delivering ABI
> stability in Swift 5.
>
> ## Changes to the language evolution process
>
> Last, I want to highlight important changes to the evolution process:
>
>   https://github.com/apple/swift-evolution#evolution-process-for-swift-5
> 
>
> With Swift 4, the release period was divided up into “stage 1” and “stage
> 2” for setting guidelines for the kind of evolution proposals that were in
> scope for the release.  This was needed to establish focus — especially
> after the churn we saw during Swift 3 — on some core themes that were
> aligned with converging the language towards source & ABI stability.  One
> downside is that “stage 2” opened up discussion for potentially disruptive
> changes fairly late in the release.  Further, some proposals — such as
> SE-0155 — came in so late that there was little runway to actually
> implement them for Swift 4, let alone evaluate their impact in practice on
> real projects.  Related, there has been some desire  for a while to be able
> to better evaluate the impact of proposals on real code before they are
> locked into the release, and the best way to do that is to actually have an
> implementation that vets out the design in a proposal.
>
> With Swift 5, the focus on ABI stability will predominate priorities for
> both design and implementation work, but the Core Team did not want