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 should mention that implicit scope for a view includes parts of the types of the arguments. #5089

Closed
scabug opened this issue Oct 19, 2011 · 11 comments
Assignees
Milestone

Comments

@scabug
Copy link

scabug commented Oct 19, 2011

This example is really weird

class O {
  def +(x: O): O = null
}
object O {
  implicit def i2o(x: Int): O = null
}
object M {
  val o : O = null
  1 + o //1.+(o) won't compile
}

This shouldn't compile in both cases. According to language specification implicit scope for e.v(args) is type of e. Here type of e is Int, so i2o can't be in implicit scope.
So this is possibly bug of lang specification, I mean implicit scope actually is bigger then Int.
However anyway it's compiler bug, because both exmples should be the same (infix operations is just syntactic sugar).

@scabug
Copy link
Author

scabug commented Oct 19, 2011

Imported From: https://issues.scala-lang.org/browse/SI-5089?orig=1
Reporter: @Alefas
Affected Versions: 2.9.1

@scabug
Copy link
Author

scabug commented Oct 19, 2011

@retronym said:
scala/scala@ae6f391

"odersky may want to take a quick look and update the spec"

http://youtrack.jetbrains.net/issue/SCL-3394

@scabug
Copy link
Author

scabug commented Nov 3, 2011

@paulp said:
I'll leave this open for the spec update, but there's no bug in the example. In "1.+(o)", "1." is a double.

scala> 1 + 2
res0: Int = 3

scala> 1.+(2)
res1: Double = 3.0

@scabug
Copy link
Author

scabug commented Nov 7, 2011

@Alefas said:
Ok, thank you, that wasn't obvious.
However maybe such syntax should be removed (I think 1d is enough)
For example, why these two calls are different?

class RichInt {
  def +++ = 1
  def foo = 2
}
implicit def i2r(x: Int): RichInt = new RichInt
1.+++
1.foo

So 1.id should be call to Int id, or should be Doudle id call in both cases.

@scabug
Copy link
Author

scabug commented Nov 7, 2011

@paulp said:
"However maybe such syntax should be removed (I think 1d is enough)"

Oh yes, I've wanted to remove it since forever. The only decent argument against is breaking code, and it's hard to believe we'd break much.

I'm not sure why +++ acts that way.

@scabug
Copy link
Author

scabug commented Nov 11, 2011

Commit Message Bot (anonymous) said:
(extempore in r25985) Deprecated ambiguous dot syntaxes.

1.+(2) - what is it? Is it 3 or 3.0? Come scala 2.11 you won't
have to not know (or even not know there's something you don't know.)
1.+(2) will then be safely considered equivalent to 1 + 2, because
any dot not followed by a digit is not part of a number.

Primarily, that's these forms: 3.f 3.d 3.

If you prefer an error to a warning, use -Xfuture.

Let's deprecate 012 == 10 too! (See comment.) References #5089, no review.

@scabug
Copy link
Author

scabug commented May 5, 2012

@retronym said:
Updated link to the unspecified change to the implicit scope:

scala/scala@7fa4ca91ff

@scabug
Copy link
Author

scabug commented Oct 15, 2013

@gkossakowski said:
Unassigning and rescheduling to M7 as previous deadline was missed.

@scabug
Copy link
Author

scabug commented Mar 13, 2014

@scabug scabug closed this as completed Mar 13, 2014
@scabug
Copy link
Author

scabug commented Mar 13, 2014

@Alefas said:
When are you planning to publish this markdown version?

@scabug
Copy link
Author

scabug commented Mar 13, 2014

@adriaanm said:
With 2.11.0 final

@scabug scabug added this to the 2.11.0-RC3 milestone Apr 7, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants