[swift-evolution] [Proposal] Type Narrowing
dennis.s.lysenko at gmail.com
Thu Nov 10 04:32:04 CST 2016
So a lot of concerns here especially ilya's are ones that wouldn't be
brought up if people looked at existing successful implementations like
Kotlin where they are clearly solved. (fyi, answer is only narrowing with
Personally I think type narrowing with explicit opt-in has no value. All or
nothing, the whole meat of the proposal is in it being implicit.
I see too many people predisposed to considering this as if it's "compiler
magic" to the point where I don't feel the cost of arguing is worth what it
would bring to the language. Sure, it's a nice piece of syntax sugar but
it's not going to revolutionise it, and if it makes compilation times even
slower I'm probably against it - xcode in general has been driving me up a
wall lately with a matter of minutes for compiling and signing our (not
huge) project, so any compiler speed improvements take on increased
precedence for me.
Just my 2c.
On Wed, Nov 9, 2016, 13:52 Haravikk via swift-evolution <
swift-evolution at swift.org> wrote:
> So I'm trying to re-write the proposal with the use of a keyword for
> unwrapping in mind, to keep it simpler for myself I've done this as two
> separate proposals for the time being, one for simpler unwrapping of
> optionals, and one for type-narrowing of polymorphic types:
> In addition to feedback on each proposal, I'm interested to know whether
> people think it is better to keep these separate? They're still very
> similar features, but the differences make it pretty awkward to keep them
> in one big proposal.
> I've also given up on integrating enums generically into it; as I don't
> think it's possible to do it in a similar enough way, and some extension to
> pattern matching would probably be better anyway.
> swift-evolution mailing list
> swift-evolution at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution