> On Aug 8, 2017, at 3:07 PM, Erica Sadun via swift-evolution 
> <swift-evolution@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

swift-evolution mailing list

Reply via email to