Type check failure in generic return types with function parameters

41 views
Skip to first unread message

yle...@gmail.com

unread,
Nov 23, 2016, 1:02:04 PM11/23/16
to scala-user
Hello all,

I was wondering if someone could explain why this code fails, since it seems trivial to me:


    case class TestClass(field: Double)
   
   
object Main {
     
def getField[T, U](obj: T, fn: T => U): U = fn(obj)
   
     
def main(args: Array[String]) = {
        val tt
= new TestClass(32.1)
        getField
(tt, _.field)
     
}
    }



The call to "getField" does not like its second parameter, when surely it should be able to determine that "[T] = TestClass".  My hunch is that it is for some reason getting a more generic type like "Any", but why?  Especially when this is fine, and surely only serves to confirm that "[T]" is what I think it is:


     getField(tt, {_.field}: TestClass => Double)



I've tried multiple variations, such as "{ x => x.field }" (doesn't work), explicitly giving "[TestClass, Double]" (works, but very verbose), "Function1[T, U]" instead of "T => U" (didn't help at all, and I didn't think it would).

This also works, and I'm not sure where the fundamental difference is in the type checking. The only problem is that this design doesn't work well for my end-target (this is obviously just a reduced example):




    case class TestClass(field: Double)
 
    object Main {
 
    implicit class Getter[T](obj: T) {
        def getField[U](fn: T => U): U = fn(obj)
   
  }
 
     
def main(args: Array[String]) = {
   
    val tt = new TestClass(32.1)
   
    tt.getField(_.field)
     
}
   
}




Any ideas?

Thanks,




Alex "Y_Less" Cole













Oliver Ruebenacker

unread,
Nov 23, 2016, 2:39:02 PM11/23/16
to yle...@gmail.com, scala-user

     Hello,

  I don't know why it does not work, but I've seen similar cases before, and you can usually make them work by replacing


  def getField[T, U](obj: T, fn: T => U): U = fn(obj)

  with

  def getField[T, U](obj: T)(fn: T => U): U = fn(obj)

  The difference is that in the first case, the compiler tries to infer both T and U jointly, while in the second case, it first solves T separately before moving on to U.

     Best, Oliver


--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-user+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



--
Oliver Ruebenacker
Senior Software Engineer, Diabetes Portal, Broad Institute

Hugo Ferreira

unread,
Nov 24, 2016, 8:34:03 AM11/24/16
to scala-user, yle...@gmail.com
To unsubscribe from this group and stop receiving emails from it, send an email to scala-user+...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

yle...@gmail.com

unread,
Nov 24, 2016, 1:50:20 PM11/24/16
to scala-user, yle...@gmail.com
Thanks for that.  I had tried to check SO, but had no idea what to call it for the search.
Reply all
Reply to author
Forward
0 new messages