Wrong Analyzer error message for required formal parameter

[sgrekhov]

Analyzer reports a wrong error message in case when required formal parameter has a default value

void foo(int i = 42) {} //   error - Named parameters must be enclosed in curly braces ('{' and '}'). - static_errors_A08_t05.dart:59:16 - named_parameter_outside_group

An error message should be like "Required formal parameter can't have a default value"

dartanalyzer version 2.7.0-dev.1.0

[bwilkerson]

The analyzer messages are designed based on our expectations of what the user was intending to do. In this case I think it's unclear whether the user was trying to declare a required parameter with a default value or an optional parameter without using either '[]' or '{}' delimiters. We chose to assume the latter because the need for delimiters might be unknown to new users. Do you know of an argument for assuming the former?

It could be argued that in this case we shouldn't make an assumption and should have a message that covers both cases, but either way we certainly shouldn't assume they were trying to define a named parameter.

[sgrekhov]

In this case I think it's unclear whether the user was trying to declare a required parameter with a default value or an optional parameter without using either '[]' or '{}' delimiters. We chose to assume the latter because the need for delimiters might be unknown to new users. Do you know of an argument for assuming the former?

@bwilkerson, below is an example

void foo(int i = 42, {String j = ""}) {} // error - Named parameters must be enclosed in curly braces ('{' and '}'). - syntax_A05_t04.dart:47:16 - named_parameter_outside_group
void bar(int i = 42, [String j = ""]) {} // error - Named parameters must be enclosed in curly braces ('{' and '}'). - syntax_A05_t04.dart:48:16 - named_parameter_outside_group

In the first line of code it is obvious that user knows about '{}' delimiters. In the second line of the code analyzer error message 'advises' to add curly braces, but it is an error to have both named and optional positioned arguments.

[bwilkerson]

Yes, it would be nice if the parser looked ahead to gather sufficient context to improve the message.