[swift-evolution] [META] Fast Track Reviews

[Brent Royal-Gordon]

> STYLE ONE: Minor language enhancements AKA "Low hanging fruit"
> 
> I would like the core team to be able to add minor language enhancements without going
> through a formal proposal process, with its normal review overhead. I have now been
> involved in several reviews that involved API changes that were otherwise unremarkable
> and primarily motivated by modernizing and style:
> 
> * Replacing Equal Signs with Colons For Attribute Arguments
> * Modernizing Playground Literals
> * Disambiguating Line Control Statements from Debugging Identifiers
> 
> To this list, you could add:
> 
> * Remove explicit use of let from Function Parameters

These examples are all very small changes, practically as easy to write as to propose comprehensively. I wonder if these sorts of things could simply be merged into master, preferably behind a feature flag if they break anything, and reviewed at the time of the next snapshot. This would allow people to actually play with the change and see how they feel about it. If people are happy with it, we remove the feature flags, finish up tests/diagnostics/documentation/deprecations, and move on. If not, modify or revert.

I think it's very important to have some kind of proposal for every change, particularly so we have a Motivations section, which is *not* something you can get from compiler diffs. I also think it's important that every change have some kind of review: it gets the idea in front of the eyes of non-compiler-writers, provides an opportunity for feedback, acts as a waiting period in case there's a better idea floating just out of reach, and legitimizes the change in the eyes of the community. (And I think all reviews, even abbreviated ones, should go out on -announce; I know a few people who can't follow swift-evolution but do read reviewed proposals to keep up with things.)

But that doesn't mean every change has to go through the same process. If the change is simple, its "proposal" can be a couple paragraphs, and its "review" can be during or after implementation, as long as it's considered non-final. We can do something lightweight for the small stuff, as long as everyone is afforded an opportunity to contribute.

(And having something already implemented may help keep bikeshedding under control. It's one thing to argue about the color before the bikeshed is painted; arguing afterward is quite another.)

> A few final thoughts
> 
> It is a given that Swift 3 is going to be the last opportunity to make large, code-breaking
> changes to the language. With that constraint, I'd like to see more time and effort go into
> improving Swift's fundamentals. Any time, effort, and review that can be better spent
> getting collections and indices right rather than worrying about colons and casing is,
> in my opinion, worth a tradeoff in community control. 

Yes and no. Colons and casing are only going to get harder to change. What I *do* think, though, is that we need to focus on getting what we have nailed down and polished up, rather than adding a bunch of new stuff. There are very few missing features which are so urgent that they can't wait* until 3.1 or 3.2 or even 4.0, but existing features' designs and names—particularly in standard library protocols—are almost frozen in the fall. 

To that end, I'm wondering if we should branch swift-evolution in the same way we branch master. swift3-evolution would focus on redesigns, minor extensions, and the few new features urgent enough to be part of Swift 3; swift-evolution would orient towards drafting and refining proposals for larger features which probably won't make the cut. (We wouldn't be reviewing these yet, but we can get things prepped.) The people who are busy implementing things can then focus on swift3-evolution and only occasionally weigh in on swift-evolution. I think this would make the current status clear and take a load off the people who are swamped.



* The only missing feature I can think of which *is* that urgent is new sequence operations to soften the blow of the C-style for loop removal. We need *something* to fix-it those old loops into.

-- 
Brent Royal-Gordon
Architechies