There is obviously a big difference here between value semantics and reference semantics. The compiler cannot reason about reference types being used in this way, but it seems like it would be able to reason about all the cases when a value type is used (value types win again!).
There is a similarity here in how we capture variables in closures, have to use self when capturing self, and have to declare @escaping vs non-escaping closures. These are all parts of the compiler reasoning about our code, and the status of an enum can similarly be reasoned about.
In the other thread cukr said:
Yeah, that thread is about making something better than if let, but there might not be anything better - they all have downsides. The main proposals all still rely on creating a new variable to replace an old one with the same name, different type - which is a bizarre thing to do when you think about it. It deserves a bizarre syntax like if let x = x to halt the reader to let them know x is about to mean something totally different.
My thread is not about fixing that - it's just about getting the compiler to know what the programmer already knows is true. It goes beyond just optionals, and it allows other enums to "unwrap" naturally as well. It's fine if it only works in 90% of the cases. Type inferencing doesn't work in every case either.
phoneyDev wrote in the other thread, regarding if myViewController != nil { }:
It makes sense that he wondered that - the programmer made an assertion that something was non-nil - the programmer knows it is non-nil, why shouldn't the compiler?