-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Ergonomics of opaque types and delegates #6716
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
Comments
Again, super quick comment (sorry for butting in without a lot of context, just had a quick discussion with Miles). |
Since the surrounding object still forms an implicit scope, is there any problem with moving the type inside the object? trait Monad[T]
class Foo
object Foo {
delegate for Monad[Foo]
}
object Bar {
opaque type Bar = Foo
delegate for Monad[Bar] = the[Monad[Foo]]
}
object Test {
import Bar.Bar
val mf = the[Monad[Foo]]
val mb = the[Monad[Bar]]
} |
We agreed that we should bring companion objects for opaque types back, as far as implicit scope is concerned. |
nice :) |
@AleksanderBG seeing as type aliases can be top level, you can type alias the opaque alias and avoid the import... :-P Or actually, you can export it (possibly pending #6729 ?). |
An opaque type and its underlying type have exactly the same representation, so it should be possible to opt to directly reuse delegates for the underlying as delegates for the opaque type. This is pretty much the gist of Andres Loh's Deriving Via paper.
Ideally we'd be able to write something like,
But this doesn't work currently, at least in part because recent changes to opaque types mean they no longer have an implicit scope of their own. The closest I think we can get right now is something like,
which has an ugly (and surely unnecessary?) cast and an untidy top-level delegate definition.
Can we do any better?
The text was updated successfully, but these errors were encountered: