Repository navigation
feat(typecheck): hint at List.concat for list addition - #168
Conversation
simontreanor
left a comment
There was a problem hiding this comment.
Thanks! The check is in the right place and the regression test is good. My only concern is the wording of the hint:
use `List.concat [a] [b]`
This reads as "wrap each side in a one-element list". Someone copying it for [1, 2] + [3] could reasonably write List.concat [[1, 2]] [[3]]. Could it say use `List.concat xs ys` instead? That matches the existing use `String.concat a b` hint next to it (and the assertion in plus_on_lists_hints_at_list_concat would change to match).
A heads-up as well: #169 also renames string_concat_hint, for the *-on-strings hint. I'm merging that one first, so this branch will need a rebase onto main. Folding the list arm into whatever the function is called by then (string_operator_hint from #169, or a more general name that covers both) is fine either way.
…xs ys Brings the branch up to date with main, where simontreanor#169 had turned the string hint into string_operator_hint for `*`. The two now share one operator_hint covering `+` on strings and lists and `*` on strings. The list hint says `List.concat xs ys`, matching `String.concat a b`, since `List.concat [a] [b]` read as wrapping each side in a one-element list.
simontreanor
left a comment
There was a problem hiding this comment.
Thanks again for this! I've pushed the change from my review so it can make the 0.10.0 release: the hint now says List.concat xs ys. I also merged main in. #169 had reworked the same helper for * on strings, so your list case and that one now share a single operator_hint. Merging once CI is green.
Suggest
List.concat [a] [b]when list operands are used with numeric+, while retaining the existing string concatenation guidance. Add a regression test for list addition and keep the generic diagnostic for unrelated numeric mismatches.Closes #134
Validation:
cargo fmt --checkcargo clippy --all-targetscargo test