Scala Programming Language
  1. Scala Programming Language
  2. SI-5044

The result of a method, taking an object of some case class, can not be assigned to a variable with the name as the name of any field of that class

    Details

      Description

      case class A(
        id: Int = 0,
        name: String = "",
        age: Int = 20
      )
      
      object Tmp {
      
        def m(a: A) = ""
        
        def main(args: Array[String]) {
          val a = A(name = "")
          val name = Tmp.m(a) // compiler error: recursive value a needs type
          println(">")
        }
      }
      

        Issue Links

          Activity

          Hide
          Mark Harrah added a comment -

          A bit simpler test case:

          val a = Option(x = "")
          val x = println(a)
          
          Show
          Mark Harrah added a comment - A bit simpler test case: val a = Option(x = "") val x = println(a)
          Hide
          Paul Phillips added a comment -

          Heh, simpler for those who know off the top of their head what the name of the parameter to Option.apply is. Fortunately that is the relevant audience.

          Show
          Paul Phillips added a comment - Heh, simpler for those who know off the top of their head what the name of the parameter to Option.apply is. Fortunately that is the relevant audience.
          Hide
          Paul Phillips added a comment -

          I say that of course because this too gives the very same error:

          val a = Option(y = "")
          val y = println(a)
          

          Not like anyone can know a priori one should work and one shouldn't.

          Show
          Paul Phillips added a comment - I say that of course because this too gives the very same error: val a = Option(y = "") val y = println(a) Not like anyone can know a priori one should work and one shouldn't.
          Hide
          Jason Zaugg added a comment - - edited

          Pretty close cousin of SI-4928

          Show
          Jason Zaugg added a comment - - edited Pretty close cousin of SI-4928
          Hide
          Lukas Rytz added a comment - - edited

          There really is a cyclic dependency: when type checking the application, we need to type-check the named argument to test if it's a valid assignment expression.

          So I think the error is not wrong. Giving an explicit type either to "a" or "y" is the correct way of fixing the code.

          However the error message is not very explicit about what to do. This is done in https://github.com/scala/scala/commit/4669ac180e58daf97ac7f73af4622434b439631d

          Show
          Lukas Rytz added a comment - - edited There really is a cyclic dependency: when type checking the application, we need to type-check the named argument to test if it's a valid assignment expression. So I think the error is not wrong. Giving an explicit type either to "a" or "y" is the correct way of fixing the code. However the error message is not very explicit about what to do. This is done in https://github.com/scala/scala/commit/4669ac180e58daf97ac7f73af4622434b439631d
          Hide
          Lukas Rytz added a comment -

          related discussion: https://github.com/lrytz/scala/commit/2ab4733e381f2e5df376b785bba9b759476e9706

          adriaanm
          is there potential for false positives here? @hubertp, what do you think?
          
          
          lrytz
          my hope is that the reporter only counts errors that are actually reported.
          the long term solution here would be to make sure "silent" is actually silent. asking the compiler if something type-checks should be one of the services that the compiler provides.
          
          
          adriaanm
          right, that sounds like a bug in silent
          I was also worried about other errors being reported, not the one you're looking for.
          Maybe you can look into the buffer for the specific error that's relevant here? Or maybe that could be another nice feature.
          
          
          lrytz
          not sure if reporters store the errors. i know that contexts do, but we don't have access to the context here (well, not to the one in which the error is reported, this one stems from a lazy type).
          i'm not too worried because cyclic references are the only kind of errors that are not silenced properly. if you get a cyclic reference type-checking "a = expr", we hope that it's related to "a". i agree it could be unrelated in principle.
          
          
          hubertp
          cyclic errors are not covered by the silent by design. Reporter only counts (or at least should) the errors that are reported, that's correct.
          It seems that the best way would be to always catch the cyclic error, log it in the buffer and re-throw, though I don't know what would be the performance impact (probably negligible since it only happens on a real error).
          
          
          lrytz
          If "silent" would actually throw the cyclic reference, that solve my problem here. but what happens is that I call "silent(typed(someTree))", and somebody catches and reports the cyclic reference.
          
          
          adriaanm
          so, maybe we can have a flag like reportAmbiguous that allows us to switch between those behaviours?
          although I should add that boolean flags are bad according to some :-)
          
          hubertp
          I think there are too many flags around already. I will have a look and see why is it reported in the first place.
          
          Show
          Lukas Rytz added a comment - related discussion: https://github.com/lrytz/scala/commit/2ab4733e381f2e5df376b785bba9b759476e9706 adriaanm is there potential for false positives here? @hubertp, what do you think? lrytz my hope is that the reporter only counts errors that are actually reported. the long term solution here would be to make sure "silent" is actually silent. asking the compiler if something type-checks should be one of the services that the compiler provides. adriaanm right, that sounds like a bug in silent I was also worried about other errors being reported, not the one you're looking for. Maybe you can look into the buffer for the specific error that's relevant here? Or maybe that could be another nice feature. lrytz not sure if reporters store the errors. i know that contexts do, but we don't have access to the context here (well, not to the one in which the error is reported, this one stems from a lazy type). i'm not too worried because cyclic references are the only kind of errors that are not silenced properly. if you get a cyclic reference type-checking "a = expr", we hope that it's related to "a". i agree it could be unrelated in principle. hubertp cyclic errors are not covered by the silent by design. Reporter only counts (or at least should) the errors that are reported, that's correct. It seems that the best way would be to always catch the cyclic error, log it in the buffer and re-throw, though I don't know what would be the performance impact (probably negligible since it only happens on a real error). lrytz If "silent" would actually throw the cyclic reference, that solve my problem here. but what happens is that I call "silent(typed(someTree))", and somebody catches and reports the cyclic reference. adriaanm so, maybe we can have a flag like reportAmbiguous that allows us to switch between those behaviours? although I should add that boolean flags are bad according to some :-) hubertp I think there are too many flags around already. I will have a look and see why is it reported in the first place.

            People

            • Assignee:
              Lukas Rytz
              Reporter:
              Yaroslav Ulanovych
            • Votes:
              0 Vote for this issue
              Watchers:
              9 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development