8000 Default getter is never assignment by som-snytt · Pull Request #6134 · scala/scala · GitHub
[go: up one dir, main page]
Skip to content

Default getter is never assignment #6134

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
Merged
merged 1 commit into from
Nov 30, 2017
Merged

Default getter is never assignment #6134

merged 1 commit into from
Nov 30, 2017

Conversation

som-snytt
Copy link
Contributor

Don't check whether supplied f(x = default$getter)
is an assignment to x.

Fixes scala/bug#10336

@scala-jenkins scala-jenkins added this to the 2.12.5 milestone Oct 15, 2017
@lrytz
Copy link
Member
lrytz commented Oct 16, 2017 •
edited
Loading

Ah, I closed the ticket before seeing this PR. LGTM, but could you mark the commit [nomerge]? IIUC it won't apply to 2.13 once #6092 is in.

@som-snytt
[nomerge] Default getter is never assignment
d505192 
Don't check whether supplied `f(x = default$getter)`
is an assignment to `x`.
@som-snytt som-snytt force-pushed the issue/10336-spur-recur branch from 2060dba to d505192 Compare October 16, 2017 21:19
@som-snytt
Copy link
Contributor Author

Thanks, this is a marginal issue but it gave me something to do on the weekend while trapped indoors by raging wildfires, or by the smoke of it.

@adriaanm adriaanm merged commit c6f7a1d into scala:2.12.x Nov 30, 2017
@som-snytt som-snytt deleted the issue/10336-spur-recur branch December 1, 2017 00:42
@SethTisue SethTisue mentioned this pull request Jan 25, 2018
Closed
@martingd
Copy link
martingd commented Apr 9, 2019

Scala compiler reinterpretation of assignment operator l op= r to l = l op r does not seem to work in Scala 2.12.3 and 2.12.4 unless both the “getter” and “setter” are defined directly on the same class/trait.

trait ReadOnly {
  def value : Int
}

trait ReadWrite extends ReadOnly {
  def value_=(i: Int) : Unit
}

class V(private var v: Int) extends ReadWrite {
  override def value = v
  override def value_=(newValue: Int) = { v = newValue }
}

val v = new V(42)
v.value += 2   // <== OK

val rw : ReadWrite = v
rw.value += 2  // <== Error

Adding override def value = v directly to trait ReadWrite makes the code compile without errors.

This bug is fixed in Scala 2.12.5 – the def value = v inherited from trait ReadOnly is sufficient to trigger the reinterpretation of += and the original example compiles without errors.

I can find no trace of such a fix neither in the release note nor by searching the issues closed. However, this issue (#6134) seems to be the best guess of what has changed the compiler's behaviour for the better. Is that the case?

I am asking because it would be a pity if the bug reappears in the future.

@som-snytt
Copy link
Contributor Author

@martingd The relevant fix was #6156 and it looks like the associated ticket is as you describe.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@lrytz lrytz lrytz approved these changes

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
2.12.5
Development

Successfully merging this pull request may close these issues.
5 participants
@som-snytt @lrytz @martingd @adriaanm @scala-jenkins
0