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
The underlying type of an opaque type is only visible to anything within
the scope that contains that opaque type. So, for instance, a Worm
opaque type in a Worms object, anything within the Worms object sees the
underlying type. So Worms.Worm is an opaque abstract type with bounds,
while Worms.this.Worm is an opaque type with an underlying type. But
you can also reference Worms.Worm while being inside of the Worms
object.
The change I made to opaque types allowed for member selection to see
the underlying type when in a scope that can see that, which makes it
consistent with how TypeComparer allows those two types to be seen as
equivalent, when in the right scope.
In kse3, it seems, the fact that this wasn't done was utilised by using
an "external" reference to the opaque type, which avoided the underlying
type's method being selected, and the extension method being selected
instead.
While my change broke kse3, I believe the change is good, as it brings
consistency. And it is possible to fix the kse3 code, by using the
"universal function call syntax" (to borrow from Rust nomenclature) for
calling the extension method. Alternatively, the extension methods can
be defined where they really don't see the underlying type, and then the
companion object can be made to include the extension methods (to keep
them in implicit scope).
0 commit comments