Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Specification: Make it an error to 'have' a method and setter with the same basename #35561

Closed
eernstg opened this issue Jan 4, 2019 · 5 comments

Comments

3 participants
@eernstg
Copy link
Member

commented Jan 4, 2019

We currently specify in section 'Class Member Conflicts' of the language specification that it is an error to declare a getter/setter and have a method with the same name, and vice versa, but this does not cover the case where two superinterfaces declare such a pair (so we don't have "a has and a declares" we just have "two has"):

abstract class A { set foo(v); }
abstract class B { void foo(); }
abstract class C implements A, B {} // No error.

It is not possible for any concrete class D to implement C, because it (or some superclass) would need to implement both the setter and the method, so there would be some class in the superclass chain from D which 'has' the setter and 'declares' the method or 'declares' the setter and 'has' the method, so we wouldn't ever have this clash in a concrete class (and hence we wouldn't have it at run time) already with the current spec, but it is better to catch this situation early such that developers don't paint anybody else into that corner.

So we should extend the specification to make this kind of clash an error already when we only have 'has' and 'has' (which will of course include all errors according to the current spec because 'declares' is a special case of 'has').

This is a non-breaking spec change, because the analyzer already rejects this kind of clash.

@eernstg eernstg added this to To do in Dart Language Specification via automation Jan 4, 2019

@eernstg

This comment has been minimized.

Copy link
Member Author

commented Jan 4, 2019

@lrhn, @leafpetersen, do you agree that we want this update?

@lrhn

This comment has been minimized.

Copy link
Member

commented Jan 4, 2019

I do!

@leafpetersen

This comment has been minimized.

Copy link
Member

commented Jan 4, 2019

SGTM, thanks.

@eernstg

This comment has been minimized.

Copy link
Member Author

commented Jan 4, 2019

Done in this CL.

dart-bot pushed a commit that referenced this issue Jan 8, 2019

Adjusted spec to make it an error to have a method - getter/setter clash
Currently, this kind of clash is an error when there is a declaration
at which the conflict is known to be an error, but it was not an error
when it occurs because a class `implements` two other classes where one
provides the getter/setter and the other provides the method.

Note to implementors: The analyzer apparently already flags this
situation as an error, so the change should be non-breaking, and if
implementation changes are needed at all it would most likely only be
in other tools.

Bug: #35561
Change-Id: I7f55b8995829ad64b86ebf33045b235813fc5161
Reviewed-on: https://dart-review.googlesource.com/c/88455
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
@eernstg

This comment has been minimized.

Copy link
Member Author

commented Jan 18, 2019

Closing: Said CL was committed in cba23af.

@eernstg eernstg closed this Jan 18, 2019

Dart Language Specification automation moved this from To do to Done Jan 18, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.