I'd personally not make this automatic, but require explicit action from the
developer.
In case of nullability, I have previously suggested "nonnil" keyword:
let foo: String? = "Hello World"
guard nonnil foo else {
return
}
In which way you explicitly request the type narrowing. Or:
let foo: Any
guard foo as String else {
return
}
I.e. not using "is" which returns a boolean, but using the cast operator, which
IMHO makes more sense and prevents from unintentional type narrowing...
> On Nov 7, 2016, at 12:34 PM, Haravikk via swift-evolution
> <swift-evolution@swift.org> wrote:
>
>
>> On 7 Nov 2016, at 03:52, Chris Lattner <clatt...@apple.com
>> <mailto:clatt...@apple.com>> wrote:
>> Introducing flow senstitive type refinement breaks this model because the
>> type of a decl depends not just on its declaration, but on a potentially
>> arbitrary number of imperative checks that occur between the declaration and
>> the use. This can make it much more difficult to understand code.
>
> This seems like more of a challenge for the IDE; if it can tap into the
> type-checker then it can determine what the narrowed type is at any given
> point in your code, indeed I would expect it to for the purposes of
> auto-completion anyway. I know you don't necessarily want a language that's
> reliant on good IDE support, but if you're doing something complex enough
> where this would become a problem and NOT using a good IDE then it seems kind
> of like a self-inflicted problem to me.
>
> Even so there's nothing in this feature that would prevent you from using
> shadowing if you want to, for example if a block is especially large and you
> feel it adds clarity.
>
> Actually though I'd say that for maintenance narrowing may be better, as it
> can clarify what a type is supposed to be at a given point, and if you break
> the narrowing then you'll create errors and warning that show you how you've
> changed the meaning of the code. Consider for example:
>
> func doSomething(value:Int?) {
> if (value == nil) { value = 5 } // value is narrow to
> Optional<Int>.some
>
> // Lots of really important code that never causes value to
> become nil
>
> print(value!.description)
> }
>
> Say you come back later and decide to remove the conditional at the top, now
> that value!, though a fair assumption at the time, can cause a runtime
> failure. With narrowing however you wouldn't have had to force unwrap because
> of the known non-nil value, but your change will break that, resulting in an
> error that forces you to fix it.
>
>
> I'm still struggling how best to phrase my motivation section; so far I seem
> to have an increasingly large grab-bag of individual problems that
> type-narrowing can solve, with no way to put it more succinctly.
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
