In the early days of Swift Evolution, the Core Team sometimes ran reviews for proposals and then decided after the review that the proposal wasn't really timely and so needed to be deferred. We stopped using this status years ago; we want reviews to end in a clear decision, and we don't want to run reviews if we're not going to be able to make that decision. However, we still have a handful of proposals in this state.
The Language Workgroup has recently been trying to clean up all the old proposals with unclear status. As part of that, we've done a review of the six remaining deferred proposals and reached a decision for each about whether to return it to be potentially reconsidered or simply reject it outright.
We have returned three proposals:
- SE-0018: Flexible memberwise initialization. We could see no reason not to return this to consideration; this seems to be a persistent pain point, and there's even a new pitch thread about it.
- SE-0078: Implement a rotate algorithm. This is readily available in the Swift Algorithms package. We might consider this for inclusion in the standard library at some future point, especially if a more satisfactory solution can be found to express performing a mutating operation on a slice of a collection. (Swift Algorithms works around this by taking a range of indices to reverse, which works, but is somewhat less nice than we might like.)
-
SE-0090: Remove
.selfand freely allow type references in expressions. This is an ongoing annoyance that we can see no reason not to clean up.
Returned proposals will need to undergo new rounds of evolution pitch and review. These proposals were never accepted, and even if they had been, they may no longer make sense for the language. In order to be reviewed, they will need to meet the new standards for review, including having a working implementation. If the original proposal author is no longer interested in advancing one of these proposals, any member of the community is welcome to take it over.
We have rejected the remaining three:
- SE-0026: Abstract classes and methods. This was originally deferred in order to gain more experience in the community about "protocol-oriented" design and whether it provides a compelling alternative to abstract classes. The Language Workgroup feels comfortable today saying that it does, and we are reluctant to add more features to encourage this style of class-oriented design.
- SE-0058: Allow Swift types to provide custom Objective-C representations. This proposal is to make official a protocol that has long existed in the standard library. Having lived with this design for many years, the Workgroup does not think that extending the set of innately bridged types would be a good idea. Giving users more power over import on a type level might be desirable, but this protocol is not the right way to do it; among other things, it is likely that that relationship would naturally be many-to-one and should be guided by annotations on the imported type, not the target type.
- SE-0083: Remove bridging behavior from dynamic casts. There is no longer any room to make this change; this is too deeply locked into the semantics of Swift, and dynamic casts are by their nature too dynamic for it to be comfortable to vary this behavior just by static context (like what language mode the cast is compiled in).
The rejection of a proposal is not necessarily permanent, but the Language Workgroup would need to see substantial new evidence or arguments in order to revisit it.
John McCall
Language Workgroup Chair