> On Jun 11, 2017, at 4:47 PM, Erica Sadun via swift-evolution
> <[email protected]> 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" and obvious that
> was never going to happen for them.
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.
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.
>
> 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.
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.
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.
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
