<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Jun 11, 2017, at 4:47 PM, Erica Sadun via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="font-family: SFHello-Regular; font-size: 15px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">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" and obvious that was never going to happen for them.</div></div></blockquote><div><br class=""></div><div>I think perhaps this was obvious in hindsight, but in fairness we **all** were still figuring out how swift-evolution worked at all in the Swift 3 timeframe and we are **still** figuring things out (as evident by this thread). When it is clear that something isn’t in scope for the current release we aren’t always omniscient about how it aligns with the next release. Swift 5, for example, hasn’t been scoped yet. There are certainly ideas, but it’s hard to say what the scoping should be for the next release until we see how the current active release shapes up.</div><div><br class=""></div><div>A lot of ideas have merit, and I know it is frustrating to not get active discussion on them as quickly as we all would like. Establishing focus for discussions is really key not only to have themes for a release (as Ben Cohen has eloquently summarized in the past) but also just prioritization. Beyond prioritizing design points that are possibly the most pressing in Swift’s usability/success as a language, there’s only so much that can be done at once. Thus there is a real balancing act between scheduling time to talk about things and actually implementing them. I mentioned this in another reply, but SE-0155 is an example of this. We discussed it, but nobody had adequate enough time to implement it so now it isn’t in scope for Swift 4. It still probably was the right thing to discuss in in the Swift 4 timeframe, but the time we did spend on it was at a direct cost to other things we could have been doing.</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div style="font-family: SFHello-Regular; font-size: 15px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: SFHello-Regular; font-size: 15px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">I think having a queue to submit "proposals for eventually", written when the inspiration is there, and having a core team review (say once a month or even once a quarter) of their viability for future Swift directions would be amazingly valuable.</div></div></blockquote><br class=""></div><div>This is a good point. I think the concern about a queue is that ideas in it may still be subject to starvation if the queue gets too long. Ideas also can atrophy in their relevance as the language evolves but proposals stay in the queue. It then becomes a delicate matter when closing out old proposals. Having the Core Team review proposals in the queue on a regular basis may be the solution, but I wonder how tenable that would be in practice. The current thinking behind closing out proposals that are out-of-scope is NOT to demoralize community participation in the evolution process, but to engage everyone in thinking about what is in scope for the release and to advocate for an idea when it makes sense for the community — and not just the Core Team — to actively engage on thinking about a proposal. If an idea doesn’t make sense for the current release but does for a later one, then (hopefully) that idea will be brought up again, and possibly incorporating new context. If anything, having a queue of a bunch of written proposals (each which can take significant effort to write) not getting much traction would possibly be even more demoralizing both for authors of the proposal but also everyone else.</div><div><br class=""></div><div>The point about understanding “viable for future Swift directions” is key here. Viability really comes down to trajectory for the language. None of us are fully omniscient about what is coming in future releases, but we do have a sense of some of the priorities for the language that we need to tackle, balanced with what **kind** of changes are still acceptable to take into the language depending on the kind of disruption they cause for users, the tools we have to mitigate any pain with those changes, etc. Discussion on swift-evolution does help shape those priorities in both specific ways and in broad strokes. However, it is hard for me to tell if all or any of the ideas you are sitting on are viable — as I don’t know what they are. I know that’s your point about having a queue of proposals. But I am skeptical that such a thing would scale or leave you thinking the process worked any better. What it sounds like to me is we need a better way to both air your ideas for consideration as well as a better understanding of the current thinking about future Swift releases. I don’t have specific ideas yet on either, although at least for the former there has been some interesting ideas mentioned on this thread.</div></body></html>