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.

Sign up for GitHub

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

Jump to bottom

fix: Only implement a deferred given in a class if its parent won't implement it #21206

Merged
merged 1 commit into from
Aug 1, 2024
Merged

fix: Only implement a deferred given in a class if its parent won't implement it #21206

merged 1 commit into from
Aug 1, 2024

Conversation

KacperFKorban
Copy link
Member

It should be possible to extend a class that inherits a deferred given, so a generated given implementation should not be final.

closes #21189

@KacperFKorban KacperFKorban marked this pull request as ready for review July 17, 2024 11:47
@KacperFKorban KacperFKorban requested a review from odersky July 23, 2024 14:27
odersky
odersky reviewed Jul 23, 2024
View reviewed changes
Copy link
Contributor

@odersky odersky left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not sure that's the right fix. Should we not simply inherit the definition in the superclass?

@KacperFKorban
Copy link
Member Author

Oooh, right. Of course, simply not generating this member in the child class should be way better, I will try to do that.

@odersky
Copy link
Contributor

odersky commented Jul 24, 2024

I think the logic should be that we implement a deferred given from trait T in class C if

  • T is a base trait of C
  • T is not a base trait of the superclass of C

@KacperFKorban KacperFKorban changed the title fix: Do not make deferred given implementations final fix: Only implement a deferred given in a class if its parent won't implement it Jul 24, 2024
odersky
odersky approved these changes Aug 1, 2024
View reviewed changes
Copy link
Contributor

@odersky odersky left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice fix!

@odersky odersky merged commit 6c4eace into scala:main Aug 1, 2024
28 checks passed
hamzaremmal added a commit to hamzaremmal/scala3 that referenced this pull request Aug 2, 2024
@hamzaremmal
Fix syntax errors introduced by scala#21206
6837445
hamzaremmal added a commit that referenced this pull request Aug 2, 2024
@hamzaremmal
Fix syntax errors introduced by #21206 (#21316)
4a28652 
Closes #21314
@WojciechMazur WojciechMazur mentioned this pull request Aug 28, 2024
Merged
WojciechMazur pushed a commit that referenced this pull request Aug 28, 2024
@hamzaremmal @WojciechMazur
Fix syntax errors introduced by #21206
90c5788 
[Cherry-picked 6837445]
WojciechMazur added a commit that referenced this pull request Aug 28, 2024
@WojciechMazur
Backport "fix: Only implement a deferred given in a class if its pare…
a80a601 
…nt won't implement it" to 3.5.2 (#21473)

Backports #21206 to the 3.5.2 branch.

PR submitted by the release tooling.
[skip ci]
WojciechMazur added a commit that referenced this pull request Aug 28, 2024
@WojciechMazur
Backport "Fix syntax errors introduced by #21206" to 3.5.2 (#21475)
73a5cc1 
Backports #21316 to the 3.5.2 branch.

PR submitted by the release tooling.
[skip ci]
@WojciechMazur WojciechMazur added this to the 3.5.2 milestone Oct 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@odersky odersky odersky approved these changes

Assignees

@odersky odersky

Labels
None yet
Projects
None yet
Milestone
3.5.2
Development

Successfully merging this pull request may close these issues.

Under experimental.modularity, cannot extend a class inheriting a deferred given
3 participants
@KacperFKorban @odersky @WojciechMazur