Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implicit resolution fails for newtypes with shapeless Lazy #3196

Open
ashleymercer opened this issue Dec 8, 2019 · 0 comments
Open

Implicit resolution fails for newtypes with shapeless Lazy #3196

ashleymercer opened this issue Dec 8, 2019 · 0 comments

Comments

@ashleymercer
Copy link
Contributor

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:

def foo(implicit tc: Lazy[Semigroup[NonEmptyChain]]): ...

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant