What is your evaluation of the proposal?
+1, after some chin-stroking.
Is the problem being addressed significant enough to warrant a change to Swift?
Does this proposal fit well with the feel and direction of Swift?
I think so. I was a bit skeptical on first blush, but two things convinced me:
- The research on the source compat suite's non-reliance on the existing behavior is compelling.
- The parallel to
as?is decisive.
When Swift is at its best, it feels simpler than it truly is because it provides a sort of heuristic consistency that allows developers to reason about disparate features using a unified mental model. (This is closely related to the idea of “progressive disclosure” that Chris Lattner talks about.)
When Swift is at its worst, it feels like a minefield of special cases because it forces developers to understand its subtle formal distinctions in ways that prevent a casual mental model from being effective.
The former should be an ongoing design goal for Swift — and the language should be willing to tolerate some judicious source breakage to support it.
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
Swift’s type promotion/conversion conveniences around Optional make it far more pleasant to use than the otherwise nearly identical Maybe types in ML family languages. I second Brent: conveniences should be convenient. And this convenience is one of Swift’s defining features.
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
Quick glance.