Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Lazy can't see through public -> private type aliases

See original GitHub issue

Java: OpenJDK 1.8.0_202 Scala: 2.12.4 shapeless: 2.3.3

Minimal reproduction: I believe all four cases shown below should compile, but only the first three do. The fourth fails because Lazy seems to lose the detailed knowledge of NonEmptyChain[String] (but works in the simple case where the first type parameter case is just String).

trait TC[F[_]]

type ValidatedString[A]    = cats.data.Validated[String, A]
type ValidatedNecString[A] = cats.data.Validated[NonEmptyChain[String], A]

{
  implicit def mkTypeClass[F[_]](implicit F: cats.Functor[F]): TC[F] = ???
  implicitly[TC[ValidatedString]]        // works
  implicitly[TC[ValidatedNecString]]     // works
}

{
  implicit def mkTypeClassLazy[F[_]](implicit F: Lazy[cats.Functor[F]]): TC[F] = ???
  implicitly[TC[ValidatedString]]        // works
  implicitly[TC[ValidatedNecString]]     // doesn't compile
}

I’ve had a look through related tickets but I don’t think this is covered elsewhere.

Issue Analytics

State:
Created 4 years ago
Comments:11 (2 by maintainers)

Top GitHub Comments

1reaction

ashleymercercommented, Dec 8, 2019

Thanks all for your input on this. Agreed, it seems like it’s not something shapeless can reasonably fix, so I’m happy for you to close. The workaround (for now at least) is to explicitly re-import the necessary implicits.

It also seems like there are other issues cats with newtypes, so I will comment there and link back to this issue.

0reactions

milessabincommented, Dec 8, 2019

It’s possible that a bit less dealiasing in the Lazy macro might help, but even if it did it would be very fragile.

I think it’s a mistake to rely on constructions which depend on aliases having different properties from their alisees (IOW, I think this is a problem with the newtype implementation) … we should have referential transparency at the type level as well as the term level.

I’ll leave this open for a bit, but I’m inclined to close it.

Top Results From Across the Web

Tracking issue for RFC 2515, "Permit impl Trait in type aliases"

One syntactic impl Trait gives you one opaque type; making an alias for it and using it in multiple places does not change...

Lazy var giving 'Instance member can not be used on type' error

Try that : class SomeClass { var coreDataStuff = CoreDataStuff! lazy var somethingElse: SomethingElse = SomethingElse(coreDataStuff: self.coreDataStuff) }.

Opaque Type Aliases: More Details - Scala 3 - EPFL

Opaque type aliases cannot be private and cannot be overridden in subclasses. Opaque type aliases cannot have a context function type as right-hand...

Lazy Computations in Java with a Lazy Type - SitePoint

But before looking at this, we must first implement type laziness. ... private String message; public String getMessage() { if (message ...

Entity types with constructors - EF Core - Microsoft Learn

The constructor can be public, private, or have any other ... field and makes it clear that it should not be set explicitly...