Skip to content

Conversation

@smarter
Copy link
Member

@smarter smarter commented Oct 19, 2018

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.

@smarter smarter added this to the 2.13.0-RC1 milestone Oct 19, 2018
@smarter smarter force-pushed the simpler-predef branch 2 times, most recently from ef444e9 to 9e6835d Compare October 19, 2018 23:20
@milessabin
Copy link
Contributor

I think the "magic" was just the general murk around implicit scopes. I'd move it to the companion and see what breaks.

@retronym
Copy link
Member

There are examples of the wild of people referring to these things with the Predef qualifier.

In this case, unimporting Predef.conforms is done at the suggestion of a Stack Overflow answer.

https://github.com/joune/dependencymanager-scala/blob/master/org.apache.felix.dependencymanager.scala.itest/src/main/scala/org.apache.felix.dm.scala.test/Activator.scala#L3-L6

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.
@smarter
Copy link
Member Author

smarter commented Oct 24, 2018

I've opened a separate PR on top of this PR where we can discuss the fate of conforms: #7369

@SethTisue
Copy link
Member

There are examples of the wild of people referring to these things with the Predef qualifier

I'm okay with that, on the balance. Anyone opposed to just merging this...?

@lrytz
Copy link
Member

lrytz commented Dec 14, 2018

It seems not :-)

@lrytz lrytz merged commit 54a8eba into scala:2.13.x Dec 14, 2018
@joroKr21
Copy link
Member

joroKr21 commented Jan 18, 2019

Shouldn't there be type aliases in Predef?

Edit: Ok I see they are in the scala package. The problem is with macros, where it's common to specify the full path from _root_ in quasi-quotes to avoid hygiene problems.

Example: https://github.com/mpilquist/simulacrum/blob/662aa50f0cbeb30bc651f1998a20863dc5d349d4/core/src/main/scala/simulacrum/typeclass.scala#L213

@SethTisue
Copy link
Member

why? (and would that even work?)

@joroKr21
Copy link
Member

joroKr21 commented Jan 18, 2019

why? (and would that even work?)

Sorry, see my edit:

Edit: Ok I see they are in the scala package. The problem is with macros, where it's common to specify the full path from root in quasi-quotes to avoid hygiene problems.

That's the change which broke simulacrum. I don't know how common it is to refer <:< and =:= in macros but it's not that far fetched. In most cases it should be possible to splice directly the type symbol:

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)?

joroKr21 added a commit to joroKr21/simulacrum that referenced this pull request Jan 18, 2019
to unblock the community build.

Ref scala/scala#7350

which moved `<:<` out of `Predef`.
@SethTisue
Copy link
Member

simulacrum is green now in the 2.13 community build thanks to your fix 👍

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

Successfully merging this pull request may close these issues.

6 participants