Comment by Mohit Athwani (JIRA)

@CodaFi I'd like to contribute to this with your assistance.

@CodaFi Let me try this!

Hey @CodaFi I have ran the exact same code, I have got this output:

warning: conditional downcast from literal to 'Character' always fails; consider using 'as' coercion
let bad = "A" as? Character
              ^

What exact type of phrasing are you looking for, because the above seems very clear and is also giving a suggestion to use the as statically coerced cast, instead of as?.

@Rajveer100 This is definitely an improvement, but I think we can take another step forward and mention the inferred type of the literal as well. I can imagine people wondering why their supposed Character literal does not want to downcast to a Character. It is not immediately clear that the destination type of a dynamic cast does not participate in the inference of the left-hand side.

Yeah I understand that, could you exactly specify to what it could be potentially changed to, what would be your suggestion?

Do you have any ideas in mind? Of course, I could just throw in a suggestion without asking you first, but to me that defeats the purpose of a good first issue.

So overall, the fix is to change the diagnosed message to a more better phrasing and provide a fix it to it if the casting is possible. While I am solving another issue, I will get back to this.

@AnthonyLatsis Back into this issue!
I guess we were discussing about the suggestions?

Hey Rajveer, got any ideas on how to improve the message yet? Suppose you compile "A" as? Character, and the compiler reacts with conditional downcast from literal to 'Character' always fails. But why does the cast fail?

In my understanding, considering the three cases of as, as? and as!:

• as is used for upcasting for bridged type
• as? is used for safe down casting (optional)
• as! is forced down casting

Considering the String case, here String is the superior type, and we are trying to downcast to a non superior Character type, which leads to failure for the last 2 cases, while the first one succeeds in doing so.

as?, as!, and is are variants of the same runtime operation. In fact, you can define as! and is in terms of as?:

• x as! T is defined to be (x as? T)!
• x is T is defined to be (x as? T) != nil

as? supports a variety of casting and conversion operations, including bridging conversions (which are not really "casting" in the traditional OO sense) as well as both up and down casting.

as is special because it is not necessarily a run-time operation, or even a conversion as such. It can act as both a known-to-succeed bridging conversion and a type inference hint or coercion, as in 0 as Double, where as simply means that 0 should be inferred to have type Double.

Okay, so the reason the cast fails is that String and Character are unrelated types. The problem is, the error message says nothing about String (the inferred type of the literal), it only says that the literal cannot be cast to Character.

Okay, so the reason the cast fails is that String and Character are unrelated types. The problem is, the error message says nothing about String (the inferred type of the literal), it only says that the literal cannot be cast to Character.

In which perspective are they 'unrelated', since a String essentially is a stream / buffer of multiple Character types, i.e., String.Element.

They are "unrelated" in the type system, not logically. "Unrelated" in this sense means that neither is a descendent (subtype) of the other. With the exception of bridging conversions and some other edge cases, Swift’s type safety implies that a type cast/coercion fails if the types are "unrelated".

That makes sense.

So we can probably update the diagnostic warning to, warning: {literal_in_context} literal and %0 are 'unrelated' to each other, consider using 'as' coercion, which in our case would be, warning: 'String' literal and 'Character' are 'unrelated' to each other, consider using 'as' coercion.

I suggest we use the same phrasing as in downcast_to_unrelated for the second half: ... to unrelated type <to_type> always fails. from <from_type> literal sounds good, but I think we can still do better by emphasizing that we are not simply describing the literal, but that the literal was inferred to that type (and only then cast), which also adds some contrast between casting (as?) and coercing (as). For example, from literal of inferred type <from_type>.

Right...