Implicit Casts for Verified Type Information

[dleuck]

I think you found the thread to which @Lantua was referring. Reviewing the previous discussion was very helpful.

It appears Lysenko and I went through the same journey of working with Kotlin's type narrowing, and wanting something like it in Swift. We also came to the same conclusions.

@Dennis_Lysenko

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.

I think the "type stack" phrasing in the proposal is throwing some people
for a loop making them think it'll have way more mental overhead than it
actually does in practice...really, in practice, I've used this either (a)
for checking nullity or (b) for checking for a specific subclass. There's
little to no mental overhead in either of those cases, as your "type stack"
is simply 2-long (this was an Int? outside of this conditional block, and
it's an Int inside. This was a UIViewController outside of this conditional
block, and it's a UINavigationController inside.)

While it may not be a panacea that allows new applications that no one
could have thought of, I have no doubt that it would greatly improve the
experience of coding in the language by, as you said, allowing more
flexibility in expressiveness. Regardless of one's opinion on the efficacy
of this feature as a whole, there are frequent situations where this
feature leads to substantially better-reading code. The "unwrap" keyword
proposed in another thread, critically, solves only half of the problems
that this proposal solves (as far as I could tell from reading a few emails
in the chain, it left the subclass inference completely untouched). Ability
to say "if (controller is SongSelectionViewController) {
controller.search(for: "mozart") }" is mentally freeing and helps me stay
in coder zen.

Exactly. It appears that this was never really resolved, or perhaps @Chris_Lattner3's post, quoted above, ended it.

The difference is that we now have a large body of code in another popular language that uses what was proposed then and now. You can always create examples where a feature like this is less obvious, as I did for type inferencing of type structure literals, and @Lantua did for type narrowing with disjunction clauses, but in the wild, it is used extensively in areas like simple switch cases and (in Kotlin), when. In these far more common cases, it makes code more readable.

@Dennis_Lysenko

The main benefit probably is that it would allow code to read much better.

I think the "type stack" phrasing in the proposal is throwing some people
for a loop making them think it'll have way more mental overhead than it
actually does in practice...really, in practice, I've used this either (a)
for checking nullity or (b) for checking for a specific subclass. There's
little to no mental overhead in either of those cases, as your "type stack"
is simply 2-long (this was an Int? outside of this conditional block, and
it's an Int inside.

I've had the same experience. In practice, Kotlin's type narrowing makes code easier to read and is not deleterious to maintainability.