> On Aug 9, 2017, at 2:30 AM, Brent Royal-Gordon via swift-evolution > <swift-evolution@swift.org> wrote: > >> 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.
The formal review has always just been a capstone of the real design process, i.e. the process of developing the proposal. Up until now, that capstone has been a lot less meaningful than it could be because there's no choice but to speculate about the actual effects of the change: whether they'll really be able to use it in all the places they think they will, how disruptive a potential source break would be, how much performance the feature actually gains/loses, etc. Some amount of speculation is appropriate — we shouldn't design just for the code that exists today — but there's no replacement for the experience of actually trying to use a feature in code that you're comfortable with. So today we have this basic development process for proposals: 1. initial proposal development (often semi-private) 2. presentation to swift-evolution 3. iterative open proposal development 4. formal review, goto 3 until confluence 5. implementation 6. feedback from implementation experience, goto 3 until confluence 7. available in a nightly build or official developer preview 8. feedback from adopters, goto 3 until confluence 9. ship it 6 and 8 will always be meaningful sources of feedback with a potential to provoke a revision. We can never completely eliminate the potential for such feedback to arrive after the formal review, because sometimes use or implementation problems only become fully apparent after you've been living with the design for a while. Still, it's somewhat absurd to ask for "final" approval for something that hasn't gone through 6 or 8 at all, and we're seeing the predictable result, where far too many proposals that are going through re-review or requiring follow-up proposals. The Swift 5 process will hopefully look more like this: 1. initial proposal development (often semi-private) 2. presentation to swift-evolution 3. iterative open proposal development 5. implementation 6. feedback from implementation experience, goto 3 until confluence 7. available for early "adoption" testing as a PR branch, ideally as a special toolchain build 8. feedback from early "adopters", goto 3 until confluence "4". formal review, goto 3 until confluence 9. ship it Your role as a proposal author really hasn't substantially changed. It's always been the case that getting something through formal review is no guarantee that it will ever be implemented, so you've never been able to just wash your hands and walk way, and you've always needed to find an implementor. The only thing that's different that we're formally recognizing the importance of having an implementation to evaluating a proposal. That happens to have the nice property that, if the proposal is accepted, it's basically guaranteed to get shipped. But your job as a non-implementing author is still primarily Steps 1-3 and evaluating all the different stages of feedback. > 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. I'm not worried about this. We've forced significant changes on an implementation before, and we'll do it again. A lot of implementation work has gone into property behaviors, and we still haven't rushed that into production. John. > 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.
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
