Suggest wrapping value in Ok or Error if it makes sense

[giacomocavalieri]

As suggested by @GearsDatapacks the compiler can now suggest to wrap a value into an Ok/Error if it would make the types line up:

pub fn main() {
  wibble(1)
//       ^ Did you mean to wrap this in an `Ok`?
}

pub fn wibble(value: Result(Int, String)) { todo }

This is a WIP because I still have to figure out how to pretty print this information in pattern matching branches, right now it looks quite bad 😁

[GearsDatapacks]

Looks like you forgot to accept the snapshot again :)

[giacomocavalieri]

Ah yeah this time it's intentional, I'm not really satisfied with how the error looks for case expressions 😆

[lpil]

Nice! Left 1 comment inline.

Could we have some tests for in use and returned from a function annotated as being result? Those will be the most common I think.

[joshi-monster]

Hey! 💜

I tried your same_as function to see if it could work for me to detect my record update type changes, and I noticed 2 problems with it where it might be too strict 🙂

• Record (Named) types are currently considered to be different types if their inferred variant differs. The way it works also affects types with only one variant.
• Unbound and generic type variables are only considered equal if they refer to the same type variable.

The last one means that your new hint doesn't work for these cases for example:

pub fn wibble() -> Result(List(String), Nil) {
  [] // List(a) `same_as` List(String)
}
pub fn wobble() -> Result(List(b), Nil) {
  [] // List(a) `same_as` List(b)
}

I feel like it would be more useful if unbound type variables where allowed to match any type on the right-hand side; Something like is_assignable_to or can_unify might maybe be more useful? Of course if that's out of scope please ignore me, I was just getting excited about that one 😊

~ yoshi

[lpil]

Hello! Are you still working on this one? Thanks

[giacomocavalieri]

Oh my I hadn't noticed the conflicts, once those are solved I think this is ready for review!

[giacomocavalieri]

This is ready now!

[lpil]

Wonderful, thank you! Left a few small notes

[lpil]

Could you merge all the ones with var on the right hand side and move the new merged clause along with clause with var on the left up to the top please.

[giacomocavalieri]

Changed it! Not sure if it's the look you wanted, let me know if it's better now

[lpil]

How come this is false?

[giacomocavalieri]

I thought an unbound variable is never meant to survive the type inference process, so I chose a safe default there

[giacomocavalieri]

This should be ready now!