Confusing incorrect arity hint when labelled arguments are provided without labels

[joshi-monster]

fn wibble(a a: Int, b b: Float, c c: String) {
  todo
}

pub fn wobble() {
  wibble(1, 2.0)
}

produces

error: Incorrect arity
  ┌─ /home/arkan/Projects/oss/gleam/probe/src/probe.gleam:6:3
  │
6 │   wibble(1, 2)
  │   ^^^^^^^^^^^^ Expected 3 arguments, got 2

This call accepts these additional labelled arguments:

  - a
  - b
  - c

I think the hint ("this call accepts these additional labelled arguments: ...") is confusing here, because I already provide values for a and b, but using positional arguments instead. While it is technically correct that I could provide any of the arguments as a labelled argument, changing the error from an incorrect arity to a type mismatch in the process, I don't think it's very useful to tell me that I could change the meaning of the arguments I already pass.

I chose different types to make it more obvious, but in my opinion all arguments that I already provide should not be included in the hint, even if the types were compatible. This is probably even more subjective. ~ 💜

[GearsDatapacks]

What should the hint say in this case? Just suggest the c label?

[joshi-monster]

I personally would want it to only suggest c since I don't ever mix positioned and labelled arguments in a way that would change their order, (e.g. only passing the second argument of a ternary function as a labelled argument), but I'm not sure if that's the best/indented experience for everyone.

[lpil]

We could remove the word "additional"?

[joshi-monster]

That might be not clear as well, since arguments that are passed as labelled arguments are removed from the list right now.

Would it maybe be possible to split the list like so?

This call is missing these arguments:

  - c c: String

Additionally, it accepts the following labelled arguments:

  - a: Int
  - b: Float

It could list positional missing arguments as well in the first list, without a label. I added type annotations in the example because I think that would also be cool, but that's probably another issue :)

[lpil]

Can you tell which ones have been supplied when it's incomplete like that?

[joshi-monster]

Do you not think that we can assume that positional arguments that type-check are valid? If they don't typecheck, you get a type mismatch error for the first one as well right now (there seem to be some inconsistencies here between positional and labelled arguments too), and if they have a label, they would still be printed anyways in the second list.

Maybe this is the assumption I make because I work this way, but is not generalisable to everyone?

[lpil]

If only positional arguments are supplied it doesn't sound too bad, but it gets less clear if there's a mix. I may be worrying about nothing!