Hint about coercion in error msg #7505
Conversation
rescript
@rescript/darwin-x64
@rescript/darwin-arm64
@rescript/linux-arm64
@rescript/linux-x64
@rescript/win32-x64
commit: |
| @@ -9,5 +9,11 @@ | |||
| This has type: [1;31mint[0m | |||
| But it's expected to have type: [1;33mfloat[0m | |||
|
|
|||
| Possible solutions: | |||
| - These types are compatible at runtime. You can use the coercion operator [1;33m:>[0m to convert to the expected type [1;33mfloat[0m. | |||
| If you want to use coercion, rewrite the highlighted code to: [1;33m(2 :> float) | |||
There was a problem hiding this comment.
Is this really a good suggestion for literals?
Wouldn't I want to write 2. + 2. rather than 2. + (2 :> float) to fix the error?
There was a problem hiding this comment.
Yeah we could ignore these cases, agreed. The int/float/string suggestions need a refactor as well now that we have new capabilities, but we can save that for later.
There was a problem hiding this comment.
Oh wow, the penny didn't yet drop for me that you can write:
let x = 4.
let y = 5
let z = x + (y :> float)Really cool!
There was a problem hiding this comment.
@nojaf yeah coercion (especially in v12) opens up a ton of cool possibilities actually. One example is that you can (together with variant type spreads) easily create fully type driven decoders:
@unboxed
type someType = One | Two | Three | Four | Five
@unboxed
type someTypeStr = | ...someType | OtherString(string)
let someTypeFromString = (s: string) =>
switch (s :> someTypeStr) {
| ...someType as someType => Some(someType)
| OtherString(_) => None
}function someTypeFromString(s) {
if (s === "One" || s === "Five" || s === "Two" || s === "Four" || s === "Three") {
return s;
}
}Can easily just add new cases to someType and have them automatically accounted for. Works because of the unboxed variant version of someType that has the OtherString(string) case, which covers any string that isn't already covered by the rest of the constructors.
| - These types are compatible at runtime. You can use the coercion operator [1;33m:>[0m to convert to the expected type [1;33mstring[0m. | ||
| If you want to use coercion, rewrite the highlighted code to: [1;33m(One :> string) |
There was a problem hiding this comment.
this is great! But I'd simplify the wording a bit, it feels a bit verbose:
| - These types are compatible at runtime. You can use the coercion operator �[1;33m:>�[0m to convert to the expected type �[1;33mstring�[0m. | |
| If you want to use coercion, rewrite the highlighted code to: �[1;33m(One :> string) | |
| - These types are compatible at runtime. You can use the coercion operator to convert to the expected type with �[1;33m(One :> string) |
There was a problem hiding this comment.
@tsnobip how would you simplify the wording? Can't see anything along those lines in the diff above.
|
@tsnobip look at the last commit please. |
| - These types are compatible at runtime. You can use the coercion operator to convert to the expected type: [1;33m(One :> string) | ||
| [0m |
This is something I've been wanting to do for a long time - hint in error messages when types are subtypes, and because of that can be coerced to the appropriate type.
I think this is going to improve the discoverability of coercion a ton, by that improve its usability.
@tsnobip @cknitt a round of message feedback please.