An overriding method can't specify a different default value

[danrubel]

The failing co19_2 tests appear to be due to missing constant evaluation or error checking after constant evaluation should be performed. I don't think that this should occur in the fasta parser or in AstBuilder, but if so, feel free to assign it to me and I'll fix.

tests/co19_2/co19_2-analyzer.status:

• Language/Classes/Abstract_Instance_Members/override_default_value_t01
• Language/Classes/Abstract_Instance_Members/override_default_value_t02
• Language/Classes/Abstract_Instance_Members/override_default_value_t03
• Language/Classes/Abstract_Instance_Members/override_default_value_t04
• Language/Classes/Abstract_Instance_Members/override_default_value_t05
• /Language/Classes/Instance_Methods/override_different_default_values_t01
• /Language/Classes/Instance_Methods/override_different_default_values_t02

[bwilkerson]

@leafpetersen Are the tests above valid? (I'm guessing the answer is "yes", but would appreciate the confirmation anyway.)

[danrubel]

Apparently, this error checking was part of ErrorVerifier and removed in Remove spec mode support from ErrorVerifier. Thanks to @bwilkerson for tracking this down.

[leafpetersen]

Yes, they look right to me.

cc @lrhn

[lrhn]

I agree that the test should give compile-time errors with the current specification.

It is a compile-time error if an instance method $m_1$ overrides an instance member $m_2$, the signature of $m_2$ explicitly specifies a default value for a formal parameter $p$, and the signature of $m_1$ implies a different default value for $p$.

[bwilkerson]

Thanks!

Just to clarify, the error reporting wasn't removed in that CL. The code that referenced the error code was removed, but the removed wasn't being run when strong mode was enabled. The removed code indicates that this error was being generated elsewhere, but I have not been able to find where that was suppose to be happening (it wasn't using this error code).

What I can tell you is that these tests were marked as failing when the co19_2 tests were created on Feb 1, 2018 (https://dart-review.googlesource.com/37743). I suspect that this error was accidentally disabled at some point during the development of strong mode. In any case, it's been broken for at least 7 months.

[natebosch]

CFE also does not report these as errors, it will be breaking to change this to an error.

[lrhn]

If no compiler implements the restriction, and it'll be a compile-time error to re-introduce it, we may want to consider just dropping the restriction.

It's not required for soundness, and it means that a subclass can't just drop the default value and use param ??= defaultValue; in code instead, even if that actually handles explicit null arguments better.
Or a sub-class can't use a more specialized default value (say const ColorPoint(0, 0, Color.black) instead of const Point(0, 0), which makes sense for covariant parameters).

[leafpetersen]

We discussed this today in the language meeting. We will demote this to a warning for the time being, and consider changing it to an error (breaking change) in the future. So the resolution of this bug is to add this back in as a warning.

[stereotype441]

Escalating to P1 since the front end has this bug too, so users are in danger of violating this warning by accident. Note that prior to landing a fix for this bug we should check that no internal code will be broken by the change.

[scheglov]

https://dart-review.googlesource.com/c/sdk/+/91170

[stereotype441]

I'm reverting 6699384 because of failures in Flutter (https://dart-review.googlesource.com/c/sdk/+/91360). Let's discuss with @leafpetersen today.

[leafpetersen]

cc @tvolkert @Hixie

This is currently a warning, and so users are free to ignore it. I'd suggest that we send a PR to flutter globally suppressing this warning, they are then free to re-enable it and fix up their code if they want the warning, and continue to ignore it if not.

[tvolkert]

We should just fix the instances that broke in Flutter to use the same default.

[Hixie]

It would be much easier to determine whether the new warnings are valid or false positives if the error message told you what the superclass' and subclass' defaults are.

[scheglov]

Sometimes. Sometimes it will not, because the value is an int, and what you really want is to reference a constant by name.

[scheglov]

@tvolkert @Hixie If these problems are warnings, will they still break Flutter?

I have a PR for Flutter, but it changes default values to make them the same as inherited, but different than they were. This might be a reason that build fails.

[tvolkert]

Yes, Flutter will still break if they're warnings.