[swift-evolution] [Proposal] Type Narrowing

[Jay Abbott]

Haravikk,

I think you missed ilya’s point with the owner/pet example:

// This is inside the Owner class...func freeMyPetIfIHaveOne {
  if pet != nil {
    pet.setFree() // this sets pet = nil
    // self.pet is now nil - not due to concurrency, it was set to nil
on this thread in the function above.
    // However, the compiler considers it a non-optional at this point
    pet.doStuff() // Compiler allows, bad things happen!
  }
}

As Dennis mentioned, narrowing only works for immutable values, and since
optionals are always mutable it defeats the whole justification for it. I
like the concept, but maybe it should be for immutables only?
​

On Thu, 10 Nov 2016 at 11:27 Haravikk via swift-evolution <
swift-evolution at swift.org> wrote:

> 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> 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-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
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> 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/2b0037e3/attachment.html>