Clarify usage of "arguments" and "parameters" in error messages #10378
Conversation
| end | ||
|
|
||
| if covered[found_index] | ||
| named_arg.raise "argument '#{named_arg.name}' already specified" | ||
| named_arg.raise "argument for parameter '#{named_arg.name}' already specified" |
There was a problem hiding this comment.
Is "for parameter" really helpful to improve this message?
There was a problem hiding this comment.
Parameters always have a name but this isn't the case for arguments (in some other error messages they are referenced by numbers like #1 and so on).
Though using "parameter ... already specified" alone is also fine to me.
There was a problem hiding this comment.
But this is about a call, so it's a duplicate argument, not a duplicate parameter.
There was a problem hiding this comment.
There cannot be duplicate arguments. Positional arguments are always identifiable by unique indices and duplicate named arguments are detected by the parser.
There was a problem hiding this comment.
Technically this is correct, yes. But from a user's perspective I would prefer not to be that specific here.
Argument 'foo' already specified is a completely sufficient error message.
There was a problem hiding this comment.
Technical correctness is the whole point of this issue. I don't see why this particular error message would be one that users prefer to be less specific than the other messages involving arguments.
There was a problem hiding this comment.
Why would shortening argument to argument for parameter be less correct? It's just more concise. Would the shortened form cause any ambiguity or misunderstanding of the error message's meaning?
| private def check_macro_param_count(a_macro, expected_count) | ||
| param_count = a_macro.args.size | ||
| if param_count != expected_count | ||
| raise TypeException.new "wrong number of parameters for macro '#{a_macro.name}' (given #{param_count}, expected #{expected_count})" |
There was a problem hiding this comment.
We are being more terse here in case of expected_count <= 1. But it's fine.
…s-parameters-errors
…s-parameters-errors
See #10374.