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

implicit disaster: typetag reifies type param instead of type argument

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: Scala 2.10.0
    • Component/s: None
    • Labels:
      None

      Description

      I spent a good half a day trying to work out a VerifyError, which I eventually tracked back to this:

      scala> def f[QVC: ClassTag] = typeTag[QVC]
      f: [QVC](implicit evidence$1: ClassTag[QVC])TypeTag[QVC]
      
      scala> f[List[Int]]
      res0: TypeTag[List[Int]] = TypeTag[QVC]
      

      I sure hope it's intended to act like this:

      
      scala> def f[QVC: TypeTag] = classTag[QVC]
      <console>:7: error: No ClassTag available for QVC
             def f[QVC: TypeTag] = classTag[QVC]
                                           ^
      

        Activity

        Hide
        Eugene Burmako added a comment -

        Yes, exactly.

        Of course, if you replace all TypeTag[T] with AbsTypeTag[T] and typeTag[T] with implicitly[AbsTypeTag[T]], then you will observe the bug that you described.

        Show
        Eugene Burmako added a comment - Yes, exactly. Of course, if you replace all TypeTag [T] with AbsTypeTag [T] and typeTag [T] with implicitly[AbsTypeTag [T] ], then you will observe the bug that you described.
        Hide
        Paul Phillips added a comment -

        I can live with that then. I'm not sure AbsTypeTag is the ideal name, especially since "ConcreteTypeTag" is spelled out, and Abstract and Concrete have the same number of letters.

        Show
        Paul Phillips added a comment - I can live with that then. I'm not sure AbsTypeTag is the ideal name, especially since "ConcreteTypeTag" is spelled out, and Abstract and Concrete have the same number of letters.
        Hide
        Eugene Burmako added a comment -

        ConcreteTypeTag was a real mouthful, and it didn't have a good contraction. Also it wasn't supposed to be used widely, whereas AbsTypeTag will be used in a lot of macros.

        Show
        Eugene Burmako added a comment - ConcreteTypeTag was a real mouthful, and it didn't have a good contraction. Also it wasn't supposed to be used widely, whereas AbsTypeTag will be used in a lot of macros.
        Hide
        Paul Phillips added a comment -

        I should also point out that "AbsXXX" is used as a name in six other places in the reflection library. In 6/6 it means "an abstract class which is extended by something else." Here you are using "Abs" for the concrete class in regards to what it represents rather than in reference to what it is. It is a naming category error to mix them.

        It isn't as if "Abs" is unambiguous, either. One can easily imagine an "absolute type tag" for instance, in contrast to a "relative" one which requires a prefix. An absent type tag, an absurd type tag... we have the means to alias long names. AbsTypeTag is still too long for me if I care about the length at all, so I'd have to alias it anyway. Why not let me alias from a name which doesn't require still more decoding.

        Show
        Paul Phillips added a comment - I should also point out that "AbsXXX" is used as a name in six other places in the reflection library. In 6/6 it means "an abstract class which is extended by something else." Here you are using "Abs" for the concrete class in regards to what it represents rather than in reference to what it is. It is a naming category error to mix them. It isn't as if "Abs" is unambiguous, either. One can easily imagine an "absolute type tag" for instance, in contrast to a "relative" one which requires a prefix. An absent type tag, an absurd type tag... we have the means to alias long names. AbsTypeTag is still too long for me if I care about the length at all, so I'd have to alias it anyway. Why not let me alias from a name which doesn't require still more decoding.
        Hide
        Eugene Burmako added a comment -

        Naming needs additional thinking, I agree.

        However, as of https://github.com/scala/scala/commit/5acac4d806eb45afdf1e7716c727a97130b69651 the root cause of the problem is fixed, so I close this bug.

        Show
        Eugene Burmako added a comment - Naming needs additional thinking, I agree. However, as of https://github.com/scala/scala/commit/5acac4d806eb45afdf1e7716c727a97130b69651 the root cause of the problem is fixed, so I close this bug.

          People

          • Assignee:
            Eugene Burmako
            Reporter:
            Paul Phillips
          • Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development