Re: [swift-evolution] Swift phases and mis-timed proposals

> Not even just for development… a standard repository for “substandard” > library(s) would be a great for commonly used types that aren’t quite > commonly used enough to include in stdlib, and IMHO, could really help > Swift’s ecosystem (I’m not claiming that it’s poor now or anything, but >

Re: [swift-evolution] Swift phases and mis-timed proposals

What if instead of a FIFO queue, we had a reddit style queue where proposals can bubble up based on community interest? It might help us figure out what to focus on in the 'phase 2' times where we allow a few out of scope proposals through... we just grab a couple off of the top. Thanks, Jon S

Re: [swift-evolution] Swift phases and mis-timed proposals

> On Jun 12, 2017, at 7:16 PM, Jonathan Hull via swift-evolution > wrote: > >> On Jun 12, 2017, at 5:12 PM, Ted Kremenek via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >>> On Jun 12, 2017, at 12:47 PM, Paul Cantrell wrote: >>> >>> Concern #2 is that it’s hard to know wh

Re: [swift-evolution] Swift phases and mis-timed proposals

> On Jun 13, 2017, at 11:46 AM, Erica Sadun via swift-evolution > wrote: > > I imagine that recent discussions like mapped keypaths, ordered sets, > `count(where:)`, etc. could have a home for discussion and exploration > without getting blocked by "out of scope" if there were a separate > "

Re: [swift-evolution] Swift phases and mis-timed proposals

> On Jun 13, 2017, at 2:07 AM, Xiaodi Wu via swift-evolution > wrote: > > On Tue, Jun 13, 2017 at 1:18 AM, Chris Lattner via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > >> On Jun 12, 2017, at 10:07 PM, Paul Cantrell via swift-evolution >> mailto:swift-evolution@swift.org>>

Re: [swift-evolution] Swift phases and mis-timed proposals

On Tue, Jun 13, 2017 at 1:18 AM, Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote: > > On Jun 12, 2017, at 10:07 PM, Paul Cantrell via swift-evolution < > swift-evolution@swift.org> wrote: > > > Perhaps the solution is not necessarily throttling proposals per se, but > having s

Re: [swift-evolution] Swift phases and mis-timed proposals

> On Jun 13, 2017, at 12:34 AM, John McCall wrote: > >> On Jun 13, 2017, at 3:22 AM, David Sweeris > > wrote: >>> On Jun 13, 2017, at 12:18 AM, John McCall via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> On Jun 13, 2017, at 1:08 AM, Jacob

Re: [swift-evolution] Swift phases and mis-timed proposals

> On Jun 13, 2017, at 3:22 AM, David Sweeris wrote: >> On Jun 13, 2017, at 12:18 AM, John McCall via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >>> On Jun 13, 2017, at 1:08 AM, Jacob Bandes-Storch via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> On Mon,

Re: [swift-evolution] Swift phases and mis-timed proposals

> On Jun 13, 2017, at 12:18 AM, John McCall via swift-evolution > wrote: > >> On Jun 13, 2017, at 1:08 AM, Jacob Bandes-Storch via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> On Mon, Jun 12, 2017 at 9:31 PM, Paul Cantrell via swift-evolution >> mailto:swift-evolution@swift

Re: [swift-evolution] Swift phases and mis-timed proposals

> On Jun 13, 2017, at 1:08 AM, Jacob Bandes-Storch via swift-evolution > wrote: > On Mon, Jun 12, 2017 at 9:31 PM, Paul Cantrell via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > I support everything Jon wrote. > > +1 Free-for-all brainstorming venue separate from focused propos

Re: [swift-evolution] Swift phases and mis-timed proposals

> On Jun 12, 2017, at 10:07 PM, Paul Cantrell via swift-evolution > wrote: > > > Perhaps the solution is not necessarily throttling proposals per se, but > having some mechanism for routing a proposal to something other than either a > review cycle or the freezer: “this needs manifesto-ing,”

Re: [swift-evolution] Swift phases and mis-timed proposals

On Mon, Jun 12, 2017 at 9:31 PM, Paul Cantrell via swift-evolution < swift-evolution@swift.org> wrote: > I support everything Jon wrote. > > +1 Free-for-all brainstorming venue separate from focused proposal > discussion. > +1, particularly for this being a section in Discourse ;-) __

Re: [swift-evolution] Swift phases and mis-timed proposals

> On Jun 12, 2017, at 7:12 PM, Ted Kremenek wrote: > > >> On Jun 12, 2017, at 12:47 PM, Paul Cantrell wrote: >> >> >>> On Jun 12, 2017, at 1:29 AM, Ted Kremenek via swift-evolution >>> wrote: >>> On Jun 11, 2017, at 4:47 PM, Erica Sadun via swift-evolution wrote: I

Re: [swift-evolution] Swift phases and mis-timed proposals

I support everything Jon wrote. +1 Free-for-all brainstorming venue separate from focused proposal discussion. +1 Working groups when helpful. +1 Longer public incubation for unstable / experimental features (but that idea executed & communicated with caution, preferably with active support fro

Re: [swift-evolution] Swift phases and mis-timed proposals

> On Jun 12, 2017, at 5:12 PM, Ted Kremenek via swift-evolution > wrote: > > - Sometimes (often?) refinements aren’t part of a grand design. They evolve > in the mind space from usage of Swift. In other words, greedy optimization > is sometimes just a natural way discussion and design happe

Re: [swift-evolution] Swift phases and mis-timed proposals

> On Jun 12, 2017, at 12:47 PM, Paul Cantrell wrote: > > >> On Jun 12, 2017, at 1:29 AM, Ted Kremenek via swift-evolution >> wrote: >> >>> On Jun 11, 2017, at 4:47 PM, Erica Sadun via swift-evolution >>> wrote: >>> >>> I think having a queue to submit "proposals for eventually", written

Re: [swift-evolution] Swift phases and mis-timed proposals

> On Jun 12, 2017, at 3:03 PM, Austin Zheng wrote: > > > The Great Access Modifiers Wars and the recent fussing of SE-110 fallout > > are good examples of these problems. > > I want to mention that SE-0110 is part of a suite of proposals originally > asked for or proposed directly by the core

Re: [swift-evolution] Swift phases and mis-timed proposals

Oh, no need to apologize! I didn't want to distract from the main point of your post, which I think is very good. The fact is that SE-0110 introduced unforeseen consequences, and that we need to deal with them one way or another (including by reverting, if it comes to that). The problem in this ca

Re: [swift-evolution] Swift phases and mis-timed proposals

> On Jun 12, 2017, at 1:29 AM, Ted Kremenek via swift-evolution > wrote: > >> On Jun 11, 2017, at 4:47 PM, Erica Sadun via swift-evolution >> wrote: >> >> I think having a queue to submit "proposals for eventually", written when >> the inspiration is there, and having a core team review (sa

Re: [swift-evolution] Swift phases and mis-timed proposals

> The Great Access Modifiers Wars and the recent fussing of SE-110 fallout are good examples of these problems. I want to mention that SE-0110 is part of a suite of proposals originally asked for or proposed directly by the core team as part of an overarching attempt to fix issues with how the typ

Re: [swift-evolution] Swift phases and mis-timed proposals

> On Jun 11, 2017, at 4:47 PM, Erica Sadun via swift-evolution > wrote: > > I am sitting on a number of ideas that I think have merit (in a non-random > use-case non-C# way) and I have no idea when the right time will be to bring > them up. Several were marked as "bring forward to Swift 4" a

Re: [swift-evolution] Swift phases and mis-timed proposals

Everyone: this is a great thread, and I appreciate the candid thoughts here. This is something Ben Cohen and I started chatting about offline and we’ll definitely bring it up for discussion with the rest of the Core Team. I realize there is a tension here, and a sense of frustration, because id

Re: [swift-evolution] Swift phases and mis-timed proposals

I have to constantly suppress all ideas (big or small) because I don't want to flood the mailing list with spam. In the case of factory initializers, it seemed like something a lot of people yearn for (myself included), so pushing for it in the wake of Swift 4 seemed like an appropriate time. Bu

Re: [swift-evolution] Swift phases and mis-timed proposals

> On Jun 11, 2017, at 3:41 PM, Haravikk via swift-evolution > wrote: > > >> On 11 Jun 2017, at 22:13, Gor Gyolchanyan via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> I agree, this makes focusing on the right types of changes much easier and >> helps us avoid turning S

Re: [swift-evolution] Swift phases and mis-timed proposals

> On Jun 11, 2017, at 14:41, Haravikk via swift-evolution > wrote: > > Thing is; people are going to have ideas when they have them, and want to > discuss them right away. I've been caught out numerous times with proposals > that are almost immediately rejected as out of scope, and still have

Re: [swift-evolution] Swift phases and mis-timed proposals

On Sun, Jun 11, 2017 at 4:41 PM, Haravikk via swift-evolution < swift-evolution@swift.org> wrote: > > On 11 Jun 2017, at 22:13, Gor Gyolchanyan via swift-evolution < > swift-evolution@swift.org> wrote: > > I agree, this makes focusing on the right types of changes much easier and > helps us avoid

Re: [swift-evolution] Swift phases and mis-timed proposals

> On 11 Jun 2017, at 22:13, Gor Gyolchanyan via swift-evolution > wrote: > > I agree, this makes focusing on the right types of changes much easier and > helps us avoid turning Swift into an incoherent conglomeration of random > use-cases (*cough*, C#, *cough*). > Now, the question is: when w

Re: [swift-evolution] Swift phases and mis-timed proposals

* I agree, that delegating initialization doesn't make sense at all, one can simply create an instance as usual. * Factory initializers are not forbidden for value types, they're simply not required to be annotated as such, due to the fact that value types don't have dynamic types and can be sim

Re: [swift-evolution] Swift phases and mis-timed proposals

I agree, this makes focusing on the right types of changes much easier and helps us avoid turning Swift into an incoherent conglomeration of random use-cases (*cough*, C#, *cough*). Now, the question is: when will be the time to officially push the factory initializers proposal and which stage s

Re: [swift-evolution] Swift phases and mis-timed proposals

I think there is merit to the current system, although it can be annoying. I’m sure we can all agree that a properly submitted and approved proposal should have solicited the fullest possible feedback at each stage, including the initial pitch stages. Based on the experience of Swift 3 evolution,

[swift-evolution] Swift phases and mis-timed proposals

I’ve read about the Swift developers taking certain kinds of proposals during certain phases (Swift 3, Swift 4 stage 1, Swift 4 stage 2, etc.). So if someone writes a proposal that isn’t of the type of the current phase, it’s auto-rejected. Is it possible to set some kind of proposal queue so th