-
Notifications
You must be signed in to change notification settings - Fork 3.1k
Move <:<, =:=, DummyImplicits out of Predef #7350
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
Conversation
ef444e9 to
9e6835d
Compare
|
I think the "magic" was just the general murk around implicit scopes. I'd move it to the companion and see what breaks. |
|
There are examples of the wild of people referring to these things with the In this case, unimporting |
There doesn't seem to be any good reason for them to be defined there. <:< and =:= are kept in the same file since =:= extends from <:< and <:< is sealed. I didn't touch $conforms because I trust what the comment above it says, but I'd like to know what the magic is exactly.
9e6835d to
df29ebb
Compare
|
I've opened a separate PR on top of this PR where we can discuss the fate of conforms: #7369 |
I'm okay with that, on the balance. Anyone opposed to just merging this...? |
|
It seems not :-) |
|
Shouldn't there be type aliases in Edit: Ok I see they are in the |
|
why? (and would that even work?) |
Sorry, see my edit:
That's the change which broke simulacrum. I don't know how common it is to refer val subType = typeOf[Any <:< Any].typeConstructor
q"val x: $A $subType $B = ..."I'm just not sure it always works. E.g. how about macro annotations (like simulacrum)? |
to unblock the community build. Ref scala/scala#7350 which moved `<:<` out of `Predef`.
|
simulacrum is green now in the 2.13 community build thanks to your fix 👍 |
There doesn't seem to be any good reason for them to be defined there.
<:< and =:= are kept in the same file since =:= extends from <:< and <:<
is sealed.
I didn't touch $conforms because I trust what the comment above it says,
but I'd like to know what the magic is exactly.