2

I made a code change within a Scala class that had been working fine. Upon trying to compile the modification, the compiler spit out the error message, "value to is not a member of Int" relating to this (pre-existing) line of code:

for (i <- 0 to cColumn -1) { ... }

Doing some research, I came across some bug reports on the "to" method - and also that "to" is apparently a method provided within the intWrapper class(?).

So, based upon that info, I started looking at my class's import statements... no such import for intWrapper. (Q: That being the case, how did this ever compile/run in the first place?) What makes this even more interesting (to me) is that when I started to do a global search in the codebase for that import I accidentally terminated the compiler (sbt) session...but when I restarted it, the class compiled just fine. No errors at all. (And no code changes from the previous session)

Anyone have any ideas as to what would cause this intermittent behavior?

NOTES:
1) using Scala 2.10.2 with javac 1.7.0_25
2) the code change to the class had nothing to do with the example functionality, nor did it alter any of the class's imports

Update: Here are the variable declarations:

val meta = rs.getMetaData()
val cColumn = meta.getColumnCount()

EDIT: Per suggestion, here is the test lines (all of them compile fine now):

implicitly[scala.Int => scala.runtime.RichInt]
intWrapper(3) to 4
for (i <- 0 to 33 -1) { /* do something smart */ }

for (i <- 0 to cColumn -1) { ... }

EDIT 2 Here is the full compiler error:

[error] /path/to/src/file/DBO.scala:329: value to is not a member of Int
[error]       for (i <- 0 to cColumn -1) {
[error]

That error was repeating ~18 times in the class. (It's a DBO-DB interface layer); where DBO.scala is the file containing the newly modified trait.

mjk
  • 659
  • 1
  • 9
  • 20

3 Answers3

4

I just encountered this same issue. In my case, it was caused by an unnecessary import, like this:

import scala.Predef.String

class Test() {
  for (t <- 1 to 3) {}
}

By default, Scala imports all of scala.Predef. Predef extends LowPriorityImplicits, which includes an implicit conversion from Int to RichInt.

to is actually defined on RichInt, so you need this conversion in order to use it. By importing just part of Predef, I lose this conversion. Get rid of the unnecessary import and the error goes away.

Tim Goodman
  • 23,308
  • 7
  • 64
  • 83
1

how did this ever compile/run in the first place?

By default, the contents of scala.Predef is imported. There you have method intWrapper which produces a RichInt with method to.

You probably have shadowed symbol intWrapper. Does the following work:

implicitly[scala.Int => scala.runtime.RichInt]

or this:

intWrapper(3) to 4

...if not, there lies your problem.

EDIT: So, since you say that compiles, what happens is you replace cColumn with a constant, e.g.

for (i <- 0 to 33 -1) { ... }

? It would also help to post the complete compiler message with indicated line etc.

0__
  • 66,707
  • 21
  • 171
  • 266
  • yep, both of those lines compile w/o a problem. If I'm understanding this correctly (I only have ~6 months code-time in Scala), it sounds like there is nothing structurally wrong with the code, but rather this was probably just some "glitch" in build system, most likely relating to the implicit imports (maybe a corrupted class-path, for example)? – mjk Aug 14 '13 at 19:00
  • If these two lines compile _within the same context_ of your `for` expression which _fails_, then I have no clue what's going on. – 0__ Aug 14 '13 at 19:18
  • I placed them directly before the example statement and they compiled OK. At this point I'm thinking it has to be glitch/bug related, which is my only concern - making sure I hadn't missed something structurally within the codebase itself. Thanks for the suggestions. – mjk Aug 14 '13 at 19:29
  • Definitely weird. The only explanation left for me is that the compiler message is actually a glitch; that is to say, there _is_ an error in your file, but somehow the compiler tells you the wrong spot. You can only try to minimise your case by commenting out things (`???` can be useful) until perhaps the mystery solves. Also perhaps try other Scala version (2.10.0, 2.10.1) to cancel out some candidates. – 0__ Aug 14 '13 at 20:19
  • Thanks for the suggestions. If I see the error start to resurface I will probably just get rid of the "to" operator altogether - which was a carry-over from my early days of learning the language. (IMO, stuff like that just creates more opportunities for bugs...kinda like what I'm seeing now!) – mjk Aug 14 '13 at 20:30
  • You _should_ use `to` and `until` to create ranges, this is the recommended way of doing it. I have never seen anything going wrong there, you must have really run into a very strange constellation, which, as I said, most likely has nothing directly to do with `RichInt`. – 0__ Aug 14 '13 at 20:45
  • Interesting you should say that, as that same Trait actually has some statements using the "until" operator...but those did not kick out any compiler errors. Are "to" and "until" actually located in different implementations? – mjk Aug 14 '13 at 20:53
  • [No, they are both in RichInt](http://www.scala-lang.org/api/current/#scala.runtime.RichInt). Have you erased the line and written it from scratch? Perhaps you have a strange character in there, something that resembles a 't' or an 'o' but actually isn't one. – 0__ Aug 14 '13 at 20:58
  • Follow-up: I'm with you so far the the possibility that there is bug in the code, albeit one that might not have anything to do with the "to" operator, but that leaves me wondering when I'm not getting error messages (of any kind) during compile, and the class/trait are operating fine when executed... – mjk Aug 14 '13 at 20:59
  • "Have you erased the line and written it from scratch?" -- it's possible, at this point that I have on one of the line instances...but definitely not on all 18 of em! – mjk Aug 14 '13 at 21:00
1

Without knowing where that error comes from, you might also try to work around it by constructing the Range by hand:

for (i <- Range.inclusive(0, cColumn-1)) { ... }

or

Range.inclusive(0, cColumn-1).foreach { i => ... }
0__
  • 66,707
  • 21
  • 171
  • 266
  • That's much more in tune with my way of thinking (now that I've had a chance to get at least some working knowledge of the language.) – mjk Aug 14 '13 at 20:35