> On Aug 8, 2017, at 3:07 PM, Erica Sadun via swift-evolution
> <[email protected]> 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
