[swift-evolution] Swift 5: start your engines

[Brent Royal-Gordon]

> On Aug 8, 2017, at 3:07 PM, Erica Sadun via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Upfront costs *will* be higher. Not only do you have to believe that a change is good, you must develop a working group that includes coders to create a prototype without any guarantee that the change will pass muster. 
> 
> Finding those coders and convincing them this will be a great change means that proposals will naturally skew towards Apple-driven rather than wider community-driven. However it does not exclude the latter, especially for passionate proposals that can find the coders to champion them.

I too think this is probably a positive step. I'd also like to point out a couple things (while reminding you that I am *not* on the core team and speak for nobody but myself):

	1. Compiler engineering is not magic. It is *especially* not magic when you're largely dealing with syntax and semantics, rather than code generation. I know it's intimidating, because a year ago I was pretty intimidated by it, but it's basically just programming in a large, complicated project with lots of weird speed hacks. And most of the standard library isn't compiler engineering at all—it's just Swift code written with a weird house style that forbids `private` and `fileprivate`. Anybody who knows enough Swift to express an intelligent opinion on its evolution should know enough to do some standard library work.

	2. We have persistently had too many designs for the available implementers. If we find that this new process overshoots and we now have too many implementers for the available designs, we can change the process again to loosen the "must include an implementation" requirement. (For instance, we might allow simpler testbed or proof-of-concept implementations, like hacky preprocessors or slightly different userspace syntaxes of things that will move into the compiler, when a full implementation would be too difficult to provide ahead of time.)

I do have some concerns about this process. I'm worried that, unless we really firm up the pre-review process, we'll end up wasting a lot of implementation time on stuff that never actually makes it into the language. I'm also worried that we'll end up accepting sub-optimal designs because the alternative is to throw out a lot of work that's already been done and defer a feature to a future version. But again, we can refine the process as we notice its problems. All of these concerns are speculative; the concern that we don't have the implementation bandwidth needed for the current design process is very real.

-- 
Brent Royal-Gordon
Architechies