> On Jun 12, 2017, at 1:29 AM, Ted Kremenek via swift-evolution > <swift-evolution@swift.org> wrote: > >> On Jun 11, 2017, at 4:47 PM, Erica Sadun via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> 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. > … > > 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.
This touches on two related concerns I’ve long had about how swift-evolution has worked so far. Concern #1 is that we consider proposals in relative isolation, on their own merits. That’s understandable and wise. Without this focus, we’d never reach conclusions about anything. However, this does tilt the process toward greedy optimization as we traverse the language space. I worry that there’s not enough attention to the big picture. Concern #2 is that it’s hard to know what to do with a proposal when the ideal answer is “we need to see how it plays out in practice and then decide whether to accept it.” Theoretical discussion untempered by practical prototyping is a great way for a group to talk itself into a bad idea. (This will especially be a problem with future work to build out generics & existentials.) Swift is already a very featureful language, and not always in a good way. A new feature that makes good sense in the context of a particular problem may make less sense when we consider the totality of its effect on the programmer model: its mental burden, its unforeseen interactions, its surprising pitfalls. How often do we reviewers give only a perfunctory answer to “Does this proposal fit well with the feel and direction of Swift?” How often _can_ we give anything but? The net result is that IMO we tend to over-favor narrow solutions that solve very specific problems, and under-favor simpler, more general features that are good-enough solutions to _many_ problems at once — not as nice for any _one_ of those problems in isolation, but nicer to work with taken as a whole. The Great Access Modifiers Wars and the recent fussing of SE-110 fallout are good examples of these problems. The work on ABI stability is perhaps a good model for non-greedy planning guided by a coherent big picture. Do these musings make sense? I don’t have any clear answers, but hope the observations are helpful. Cheers, Paul _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
