[swift-evolution] [Proposal] Type Narrowing

[Jean-Daniel]

> Le 14 nov. 2016 à 10:10, Haravikk <swift-evolution at haravikk.me> a écrit :
> 
> 
>> On 13 Nov 2016, at 16:16, Jean-Daniel via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>>> 
>>> Le 13 nov. 2016 à 03:37, Dennis Lysenko via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> a écrit :
>>> 
>>> That's a good point in Jay's example and from what I can tell a good way to address it, Haravikk. 
>>> 
>>> I've done some work in a language that only provides type narrowing for immutable types (that'd be Kotlin as I've mentioned before) and whenever I've used it it feels like the only thing it's really been missing is the "if let" construct allowing you to bind and unwrap mutable values, which leads me to think that synergistically, in Swift, this would be fantastic. The main benefit probably is that it would allow code to read much better.
>> 
>> IMHO, the Kotlin solution is flaw. The fact that type narrowing does not works for var and that there is no simple way to unwrap optional just force the developer either to introduce local variable, or to use the force unwrap operator.
>> Moreover, introducing a unwrap syntax (if let) like in swift would just result in having 2 different and inconsistent way to do the same thing.
> 
> I'll have to take a closer look at how Kotlin does this when I get a chance, but how would this affect the two proposals as they currently stand?
> 
> 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>
> 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>
> 
> These keep automatic narrowing of polymorphic types, but requires explicit narrow/unwrapping of optionals (because we can define methods/properties on Optional there's no other choice unfortunately); it would work for both mutable and immutable values, but mutable reference types require an extra step due to the potential for unsafe operations.
> 
> I think that's about as flexible as we're going to be able to get without introducing other difficulties.

While the proposals try to be less restrictive than Kotlin, I don’t like the way they handle concurrency.
All usage of the ‘!’ operator in swift guarantee a crash at the call site if something is wrong (try!, as!, optional!, …). In the proposals, the ‘!’ operator means that the app may crash at call site or may crash later.



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