[swift-evolution] Swift phases and mis-timed proposals
erica at ericasadun.com
Tue Jun 13 13:46:44 CDT 2017
> On Jun 13, 2017, at 2:07 AM, Xiaodi Wu via swift-evolution <swift-evolution at swift.org> wrote:
> On Tue, Jun 13, 2017 at 1:18 AM, Chris Lattner via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> On Jun 12, 2017, at 10:07 PM, Paul Cantrell via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> Perhaps the solution is not necessarily throttling proposals per se, but having some mechanism for routing a proposal to something other than either a review cycle or the freezer: “this needs manifesto-ing,” “this needs prototyping to measure impact on existing code,” “this needs to simmer and find its context before we work it into a proposal,” etc. (That’s related to Daryle’s original message.)
> I feel like I’m missing some part of the motivation for this thread. Let me try to explain why:
> Lets say you’re interested in proposing a new feature or idea today, and are told that it is out of scope. One of two things happen. When the next release comes around, either:
> 1) if you’re still engaged with swift-evolution, you can bring it back up.
> 2) if you’re not still engaged, it will get dropped unless someone else is interested in championing it.
> What good does a “queue” of proposals in the freezer do? In practice, getting a proposal to happen frequently requires editing and iteration, not to mention active discussion about motivation. We have no shortage of important proposals to get through in each release, why should we make it easier for proposals with no active proponent? Wouldn’t that just encourage people to drop off “drive-by” proposals for ideas?
> I think this goes to the discussion above about what kind of list this is to be. We've got, on the one hand, a significant number of proposals of the following sort: how should indexing into the middle of a grapheme be handled? which integer protocols should have the bitwise operators? These require editing and iteration, as you say, and very active back-and-forth discussion. These days it seems these sorts of threads rarely gain the greatest attention. The most useful kind of feedback in such a discussion would be a detailed and robust critique; much less useful is the ever more common "+1," and storing the proposal in a freezer is the surest way to irrelevance as the detailed design can quickly become nonsensical due to even small changes elsewhere.
> There are, however, a significant number of conversations that, at base, are declarations that there exists some problem or issue. It's not straightforwardly a bug that can be filed, and it's not a user knowledge issue that can be solved by a question to swift-users, but it's something else that may require a language change. This is, of course, a perfectly understandable state of affairs for which some forum should probably exist. However, the "format" of Swift Evolution requires a proposed solution and detailed design, so the author feels compelled to put down _something_ that might alleviate the problem. Frequently, later in the discussion, the author will reply that he or she isn't actually married to the proposed solution and/or does not really know if the detailed design will work at all, but wanted the community to acknowledge that a problem or issue exists and needs attention. Critiquing the placeholder proposed solution and detailed design is kind of beside the point, even though it's the ostensible purpose of this list. If anything is helpful in this scenario, it would be feedback that validates and expounds on the issue (or in the absence of that, "+1"). However, there's not an iterative process that will take you from that point to an implementable design. It might be, however, a topic that fits nicely into a "queue" of some sort.
> There's another class of conversations that, from what I can tell, boil down to a request for a feature--often one that is highly desired by many people. The feature doesn't yet exist because it would require extensive design and implementation effort. Perhaps the author is unaware that the feature is already widely desired, or perhaps the author simply wants to make it known that they wish that it would take higher priority. The actual motivation for starting a thread isn't the promotion of any particular design for the desired feature, just the feature itself. Also a perfectly understandable situation, and should be accommodated in some form, somewhere. However, Swift Evolution requires a detailed design, so the author feels compelled to sketch out some sort of placeholder; sometimes, the "detailed design" recites more and more elaborate variations of the feature but makes no attempt to actually describe how it will come to be. Again, little point in critiquing it. Again, there's not an iterative process from there to implementable design. This time the topic is almost a meta-discussion on the proper prioritization of items in the "queue" of ideas, and the responses that are relevant to such a conversation (short of designing and implementing the feature) can really only be "yes, I want this feature too."
Most proposals break down to one of:
* Adjusting the language to add features that match development ideals (usually under a manifesto umbrella)
* Fixing problems in the language that lead to inefficient compiler implementation / unnecessary complexity
* Adding features to the language to match common compilation options found elsewhere (the recent re-emergence of #warning/#error being a good example)
* Fixing problems in the language that lead to unsafe code
* Getting SwiftPM into shape ("ballardization")
* Editing the standard library to remove or add features for a more robust and cleaner API experience
* Adding features to the language to match common language features found in other modern programming languages
My personal interest lies in the fourth bullet ("Fixing problems in the language that lead to unsafe code"). Friends and I have found through experience a fair number of areas where the language can be adjusted to increase safety, and we've brainstormed ways to do so additively without breaking backward compatibility. There never seems to be a good time or place to introduce these ideas.
Of the remaining bullet points, the last 2 (new library features) seem like they *could* be developed, tested, and implemented independently of the standard SE process until the language is at a point (Swift 5 or Swift 6) where it becomes open to additive features.
I imagine that recent discussions like mapped keypaths, ordered sets, `count(where:)`, etc. could have a home for discussion and exploration without getting blocked by "out of scope" if there were a separate "Substandard Library" repository, mailing list, and process (potentially staffed in part or full by non-Apple personnel) that did not rely on internal Apple timelines and delivery benchmarks. Think "farm league for SE" (https://en.wikipedia.org/wiki/Farm_team <https://en.wikipedia.org/wiki/Farm_team>). It would lower the burden on SE but provide a way forward to discuss and develop ideas within the framework of coherent language design.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution