Re: [swift-evolution] [planning] [discussion] Schedule for return of closure parameter labels (+ world domination ramble)

> If you’re into analogies, I see features like the generics improvements, > concurrency model, ownership system, macro system, ABI stability, new > frameworks, and other large scale efforts as the “bricks" that make up the > house of Swift. In that analogy, smaller proposals are “mortar”

Re: [swift-evolution] [planning] [discussion] Schedule for return of closure parameter labels (+ world domination ramble)

Perfect, thanks! On Tue, Aug 8, 2017 at 7:25 PM, Douglas Gregor wrote: > On Aug 8, 2017, at 10:44 AM, Mathew Huusko V via swift-evolution < > swift-evolution@swift.org> wrote: > > Sorry to revive this, but back on my ABI stability education: > > > [We’re a bit far afield of

Re: [swift-evolution] [planning] [discussion] Schedule for return of closure parameter labels (+ world domination ramble)

> On Aug 8, 2017, at 10:44 AM, Mathew Huusko V via swift-evolution > wrote: > > Sorry to revive this, but back on my ABI stability education: [We’re a bit far afield of the original subject, but okay] > > Swift 5 planning was announced today (woohoo!) with a

Re: [swift-evolution] [planning] [discussion] Schedule for return of closure parameter labels (+ world domination ramble)

The key difference is whether such things can be rolled out in the future in an additive way, potentially with extra compatibility affordances, vs whether something is inherent to the ABI as Swift and the standard library currently exists. This is a very fuzzy line, and is constantly getting

Re: [swift-evolution] [planning] [discussion] Schedule for return of closure parameter labels (+ world domination ramble)

Sorry to revive this, but back on my ABI stability education: Swift 5 planning was announced today (woohoo!) with a primary target on ABI stability. Finalising generics seems to be a major part of this, with "conditional conformances", "recursive protocol requirements," and "there are no known

Re: [swift-evolution] [planning] [discussion] Schedule for return of closure parameter labels (+ world domination ramble)

> On Aug 7, 2017, at 11:34 PM, Elviro Rocca > wrote: > > I agree with everything you wrote, in particular I agree with the idea that > it is more important to get the big efforts right, and that they should take > priority. But I would consider a distinction:

Re: [swift-evolution] [planning] [discussion] Schedule for return of closure parameter labels (+ world domination ramble)

I agree with everything you wrote, in particular I agree with the idea that it is more important to get the big efforts right, and that they should take priority. But I would consider a distinction: - big efforts that add huge new features to the language so that things that were done in

Re: [swift-evolution] [planning] [discussion] Schedule for return of closure parameter labels (+ world domination ramble)

On Mon, Aug 7, 2017 at 12:12 PM, Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote: > > > On Aug 7, 2017, at 12:43 AM, Elviro Rocca com> wrote: > > > > I read many times the "most users don't care about this" objection but I > always considered it

Re: [swift-evolution] [planning] [discussion] Schedule for return of closure parameter labels (+ world domination ramble)

> On Aug 7, 2017, at 12:43 AM, Elviro Rocca > wrote: > > I read many times the "most users don't care about this" objection but I > always considered it more like an argument for postponing something than > removing it completely from the Swift equation (I

Re: [swift-evolution] [planning] [discussion] Schedule for return of closure parameter labels (+ world domination ramble)

I read many times the "most users don't care about this" objection but I always considered it more like an argument for postponing something than removing it completely from the Swift equation (I believe I also read words like that from yourself, Chris), because there is a point about

Re: [swift-evolution] [planning] [discussion] Schedule for return of closure parameter labels (+ world domination ramble)

Ah, I see. I understood on a basic level that additive features were safe, but I didn't/don't have the knowledge to judge when adding actually means changing (e.g. idk, 'adding abstract classes' or 'adding optional protocol methods' implying 'changing/breaking inheritance/dispatch' or

Re: [swift-evolution] [planning] [discussion] Schedule for return of closure parameter labels (+ world domination ramble)

> On Aug 4, 2017, at 12:03 PM, Mathew Huusko V wrote: > > Thanks for the swift response, it's an honour; I agree wholeheartedly with > your logic and sentiment. Sorry if I was unclear, but my concern/curiosity is > not for the speed of Swift's development, but in fact for

Re: [swift-evolution] [planning] [discussion] Schedule for return of closure parameter labels (+ world domination ramble)

Thanks for the swift response, it's an honour; I agree wholeheartedly with your logic and sentiment. Sorry if I was unclear, but my concern/curiosity is not for the speed of Swift's development, but in fact for its long term evolution and longevity. At risk of repeating myself/boring everyone,

Re: [swift-evolution] [planning] [discussion] Schedule for return of closure parameter labels (+ world domination ramble)

> On Aug 4, 2017, at 9:16 AM, Mathew Huusko V via swift-evolution > wrote: > > Per > https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000233.html > > , > the

[swift-evolution] [planning] [discussion] Schedule for return of closure parameter labels (+ world domination ramble)

Per https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000233.html, the removal of parameter labels entirely was accepted as a temporary loss for Swift 3 as a means to remove them from the type system. I'm wondering if they're coming back (syntactically) any time soon? Other