You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
ClassTags are used by scalac during type-based pattern matching. This is a problem for newtypes (but not newsubtypes) since their ClassTag runtime class is Object. As such, we are permitting users via our "safe" API to do unsafe things without it being obvious that what they are doing will definitely result in a runtime exception.
scala>importio.estatico.newtype.macros._, io.estatico.newtype.ops._
scala>@newtype caseclassFoo(x: String)
scala> (1:Any) match { casex: Foo=> x ; case _ =>Foo("nope") }
res0:Foo=1
scala> res0.coerce[String]
java.lang.ClassCastException: java.lang.Integer cannot be cast to java.lang.String
... 38 elided
I think the solution for now is to remove ClassTag instances altogether. The only reason I think they're useful is for constructing Arrays, but I think this is the wrong solution. I have an experimental (and incomplete) branch for a different way of handling Arrays here (via an AsArray type class). I'm looking to try to use this to resolve #10 in a type safe way.
In the meantime, I think it's best to remove the ClassTag instances to prevent unsafe code from happening by accident.
Also see my original point about this with regard to the unapply method here.
The text was updated successfully, but these errors were encountered:
/cc @joroKr21 See the above comment regarding the removal of ClassTag instances. I think the work being done for #10 should eliminate the need for them, but feel free to let me know if I'm missing something.
ClassTags are used by scalac during type-based pattern matching. This is a problem for newtypes (but not newsubtypes) since their ClassTag runtime class is
Object
. As such, we are permitting users via our "safe" API to do unsafe things without it being obvious that what they are doing will definitely result in a runtime exception.I think the solution for now is to remove ClassTag instances altogether. The only reason I think they're useful is for constructing Arrays, but I think this is the wrong solution. I have an experimental (and incomplete) branch for a different way of handling Arrays here (via an
AsArray
type class). I'm looking to try to use this to resolve #10 in a type safe way.In the meantime, I think it's best to remove the ClassTag instances to prevent unsafe code from happening by accident.
Also see my original point about this with regard to the
unapply
method here.The text was updated successfully, but these errors were encountered: