[swift-evolution] [Proposal] Type Narrowing

[Haravikk]

> On 10 Nov 2016, at 10:32, Dennis Lysenko <dennis.s.lysenko at gmail.com> wrote:
> 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 immutable values.)
> 
> 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.
> 
Right you are, I think an explicit keyword is only required for optionals; stripping them out into their own proposal simplifies things considerably. I've tweaked the type-narrowing specific proposal to return implicit narrowing (or explicit via the is keyword and assignment, depending upon how you want to look at it).

I do think there is still value in handling reference types as well, but I'm proposing that this is done with a new force is! keyword which forces the narrowing (but causes a runtime concurrent modification error if the type no longer matches what the type-checker expects), as well as a new @concurrency(safe) attribute that can be used to indicate variables that posses a safe reference to an instance, e.g- for types that use a storage class for copy-on-write functionality, or where the value is local to a method etc. (though this isn't enforced).
> 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.
> 
While I agree that the current performance can leave a lot to be desired, I don't think that this should actually slow it down by any meaningful amount; most variables won't narrow so will just be a single type as normal, and with optionals removed from the narrowing process the type-checker should only ever need to compare against the narrowest type on the stack, i.e- the only time wider types are considered is when you assign a wider type to a narrowed variable, and that's just popping types off the stack to get the new current type.

But yeah, if it were have a big impact on performance I'd recommend delaying it until major optimisation work has been done, but I don't see that it should make much of a difference, and it really shouldn't be any more of a burden than shadowing is today.

>> On Wed, Nov 9, 2016, 13:52 Haravikk via swift-evolution <swift-evolution at swift.org <mailto: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:
>> 
>> https://github.com/Haravikk/swift-evolution/blob/master/proposals/NNNN-optional-unwrapping.md <https://github.com/Haravikk/swift-evolution/blob/master/proposals/NNNN-optional-unwrapping.md>
>> https://github.com/Haravikk/swift-evolution/blob/master/proposals/NNNN-type-narrowing.md <https://github.com/Haravikk/swift-evolution/blob/master/proposals/NNNN-type-narrowing.md>
>> 
>> 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 <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161110/d55b1c40/attachment.html>