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
Several types in cats such as NonEmptyChain are defined using the newts / newtypes approach: the advantage of this is that there is zero (runtime) overhead to using these types versus the possibly-empty equivalents; however, it leads to several issues, raised here and elsewhere:
To this list I would like to add an issue with implicit resolution when using shapeless Lazy: see milessabin/shapeless#942 for the gory details but, in short, it's impossible to write something like:
The non-Lazy version works just fine (as do by-name implicits in scala 2.13+). Interestingly, the Lazy version does work if either (or both) of the following are true:
the implementation class (NonEmptyChainImpl in this case) is public
the required implicits are explicitly re-imported at the call site (import NonEmptyChain._)
Clearly the end-user can't control the first, and the second is far from ideal (and took several days to discover as a workaround).
It seems like a lot of these issues boil down to variations on scala/bug#6794 and, given that this is unlikely to be fixed in its entirety any time soon, is there some benefit to considering moving away from newtype altogether?
The text was updated successfully, but these errors were encountered:
Several types in cats such as
NonEmptyChain
are defined using the newts / newtypes approach: the advantage of this is that there is zero (runtime) overhead to using these types versus the possibly-empty equivalents; however, it leads to several issues, raised here and elsewhere:cats.data.Newtype
(via NonEmptySet) #2582To this list I would like to add an issue with implicit resolution when using shapeless
Lazy
: see milessabin/shapeless#942 for the gory details but, in short, it's impossible to write something like:The non-
Lazy
version works just fine (as do by-name implicits in scala 2.13+). Interestingly, theLazy
version does work if either (or both) of the following are true:NonEmptyChainImpl
in this case) is publicimport NonEmptyChain._
)Clearly the end-user can't control the first, and the second is far from ideal (and took several days to discover as a workaround).
It seems like a lot of these issues boil down to variations on scala/bug#6794 and, given that this is unlikely to be fixed in its entirety any time soon, is there some benefit to considering moving away from newtype altogether?
The text was updated successfully, but these errors were encountered: