> On 10 Nov 2016, at 10:32, Dennis Lysenko <[email protected]> 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 >> <[email protected] <mailto:[email protected]>> 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 >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
