Skip to content

SIP-33 - Priority-based infix type precedence#6147

Closed
soronpo wants to merge 1 commit intoscala:2.13.xfrom
soronpo:sip33-2.13.x
Closed

SIP-33 - Priority-based infix type precedence#6147
soronpo wants to merge 1 commit intoscala:2.13.xfrom
soronpo:sip33-2.13.x

Conversation

@soronpo
Copy link

@soronpo soronpo commented Oct 25, 2017

Implements SIP33: Priority-based infix type precedence
https://docs.scala-lang.org/sips/priority-based-infix-type-precedence.html

@scala-jenkins scala-jenkins added this to the 2.13.0-M3 milestone Oct 25, 2017
@soronpo
Copy link
Author

soronpo commented Nov 17, 2017

@milessabin or @SethTisue please trigger community-build check for this PR.

@adriaanm adriaanm modified the milestones: 2.13.0-M3, 2.13.0-M4 Dec 13, 2017
@SethTisue
Copy link
Member

@soronpo I seem to have dropped the ball there, sorry. if you rebase this against current 2.13.x, I'll run the community build.

@SethTisue SethTisue added the WIP label Feb 24, 2018
@adriaanm adriaanm modified the milestones: 2.13.0-M4, 2.13.0-M5 Apr 30, 2018
@dwijnand
Copy link
Member

@soronpo Just a (re) heads up: this is currently failing on Jenkins and it has merge conflicts with the target branch. Given SIP-33 has been accepted, it would be lovely to actually ship it too! 😄

@soronpo
Copy link
Author

soronpo commented Jun 12, 2018

Yeah, thanks. I was waiting for the 2.13-M4 community build to stabilize on green before resolving this issue (because I want to make sure I'm not breaking anything).

@soronpo
Copy link
Author

soronpo commented Jul 31, 2018

@SethTisue can you please run a community build for this branch?

@SethTisue
Copy link
Member

I was waiting for the 2.13-M4 community build to stabilize on green

there are currently 46 green projects in the 2.13 build (out of ~170). that's enough to give some assurance. stronger additional assurance is available if you backport a change to 2.12.x (even if it's not intended to actually be merged there) and run the community build on that.

I'll trigger a build for you sometime today.

@SethTisue
Copy link
Member

@soronpo
Copy link
Author

soronpo commented Aug 2, 2018

@SethTisue why was the build aborted?

@soronpo
Copy link
Author

soronpo commented Aug 2, 2018

NM, I've now noticed the parsed outputs. Gives a much clearer picture of what is going on.

@SethTisue
Copy link
Member

SethTisue commented Aug 2, 2018

the build aborted because nscala-time's tests hung. might be related to the PR, or might be transient, let's try again: https://scala-ci.typesafe.com/job/scala-2.13.x-integrate-community-build/1292/

@SethTisue
Copy link
Member

[kind-projector] [info] ======= Position error
[kind-projector] [info] Enclosing tree [527] does not include tree [432]
[kind-projector] [info] == Enclosing tree [527] of type AppliedTypeTree at [450:454]hmm.scala
[kind-projector] [info] [L  16        ] #527    [450:454]       AppliedTypeTree // :: In
[kind-projector] [info] == Enclosed tree [432] of type Ident at [280:282]hmm.scala
[kind-projector] [info] [L  16        ] #432    [280:282]       Ident      // :: 
[kind-projector] [info] 
[kind-projector] [info] While validating #1217
[kind-projector] [info] [L   1        ] #1217   [0:1733]        PackageDef // hmm
[kind-projector] [info] 
[kind-projector] [info] Children:
[kind-projector] [info]   [L   1 P# 1217] #353    [8:11]          Ident      // hmm
[kind-projector] [info]   [L   3 P# 1217] #363    [13:24]         ClassDef   // TC[A]
[kind-projector] [info]   [L   5 P# 1217] #378    [26:65]         ModuleDef  // TC {
[kind-projector] [info]   [L   9 P# 1217] #1216   [67:1733]       ModuleDef  // test {
[kind-projector] [info] =======

@SethTisue
Copy link
Member

@soronpo where do we stand, here?

@soronpo
Copy link
Author

soronpo commented Nov 6, 2018

It's a bit problematic for me to debug the issue since the failure is in a compiler-plugin (kind-projector).
I'm currently overloaded with work, and hope to be getting back to this issue next month.

@SethTisue
Copy link
Member

okay. we can reopen the ticket when work resumes.

It's a bit problematic for me to debug the issue since the failure is in a compiler-plugin (kind-projector)

I see... feel free to ask for help (here, or on Gitter or Discourse) with workflow issues

@SethTisue SethTisue closed this Nov 6, 2018
@SethTisue SethTisue removed this from the 2.13.0-RC1 milestone Feb 22, 2019
smarter added a commit to smarter/scala that referenced this pull request Apr 25, 2021
Instead of:

    val x: A with B = new A with B {}

One can now write:

    val x: A & B = new A with B {}

However mixing `&` with other infix operators is not allowed, because
unlike Scala 3, we do not take operator precedence into account, cf scala#6147.
smarter added a commit to smarter/scala that referenced this pull request Apr 25, 2021
Instead of:

    val x: A with B = new A with B {}

One can now write:

    val x: A & B = new A with B {}

However mixing `&` with other infix operators is not allowed, because
unlike Scala 3, we do not take operator precedence into account, cf scala#6147.
smarter added a commit to smarter/scala that referenced this pull request Apr 25, 2021
Instead of:

    val x: A with B = new A with B {}

One can now write:

    val x: A & B = new A with B {}

However mixing `&` with other infix operators is not allowed, because
unlike Scala 3, we do not take operator precedence into account, cf scala#6147.

This implementation is a bit more restrictive than the Scala 3 one which
allows shadowing the built-in `&` with your own `&` type operator, but
this cannot be done with the simple parser-based approach of this PR.
smarter added a commit to smarter/scala that referenced this pull request Apr 25, 2021
Instead of:

    val x: A with B = new A with B {}

One can now write:

    val x: A & B = new A with B {}

However mixing `&` with other infix operators is not allowed, because
unlike Scala 3, we do not take operator precedence into account, cf scala#6147.

This implementation is a bit more restrictive than the Scala 3 one which
allows shadowing the built-in `&` with your own `&` type operator, but
this cannot be done with the simple parser-based approach of this PR.
smarter added a commit to smarter/scala that referenced this pull request Apr 25, 2021
Instead of:

    val x: A with B = new A with B {}

One can now write:

    val x: A & B = new A with B {}

However mixing `&` with other infix operators is not allowed, because
unlike Scala 3, we do not take operator precedence into account, cf scala#6147.

This implementation is a bit more restrictive than the Scala 3 one which
allows shadowing the built-in `&` with your own `&` type operator, but
this cannot be done with the simple parser-based approach of this PR.
smarter added a commit to smarter/scala that referenced this pull request Apr 25, 2021
Instead of:

    val x: A with B = new A with B {}

One can now write:

    val x: A & B = new A with B {}

However mixing `&` with other infix operators is not allowed, because
unlike Scala 3, we do not take operator precedence into account, cf scala#6147.

This implementation is a bit more restrictive than the Scala 3 one which
allows shadowing the built-in `&` with your own `&` type operator, but
this cannot be done with the simple parser-based approach of this PR.
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.

5 participants