Skip to content
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

Fewer braces are part of the language from 3.3.x #14561

Closed
wants to merge 4 commits into from

Conversation

soronpo
Copy link
Contributor

@soronpo soronpo commented Feb 24, 2022

This PR removes the language.experimental.fewerBraces flag and always enables the "fewerBraces" syntax feature.

@soronpo soronpo added this to the 3.2.0-RC1 milestone Feb 24, 2022
@soronpo soronpo requested a review from odersky February 24, 2022 23:22
@soronpo
Copy link
Contributor Author

soronpo commented Feb 24, 2022

@odersky I wanted to enable this feature, but it seems not everything is ironed-out just yet.

Error:  29 |    assertTrue((new js.Object: Any).isInstanceOf[Object])
Error:     |                                  ^
Error:     |                                  an identifier expected, but ')' found

If we sill consider the above a legal syntax, then there seem to be a bug in the implementation of fewerBraces.

Copy link
Member

@smarter smarter left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can't just enable a feature like this. It needs to get discussed and approved by the SIP committee first.

@odersky
Copy link
Contributor

odersky commented Feb 25, 2022

I would personally be very much in favor of including this in 3.2.

@soronpo
Copy link
Contributor Author

soronpo commented Feb 25, 2022

We can't just enable a feature like this. It needs to get discussed and approved by the SIP committee first.

I completely lost track of the governance for language changes. I have not seen the SIP committee convene in ages, and that includes the majority of Scala 3 changes that occurred and still occurring. It would be helpful if we were consistent about applying this policy.

@smarter
Copy link
Member

smarter commented Feb 25, 2022

My understanding is that the scala center is in the process of restarting the sip committee but I don't know what the timeline is. I don't think we made any language change since 3.0 that would have required going through it so far.

@soronpo
Copy link
Contributor Author

soronpo commented Feb 25, 2022

I pushed the fix in #14562 to see if all tests pass, including the community build, if this feature is always enabled.

@soronpo
Copy link
Contributor Author

soronpo commented Feb 25, 2022

I don't think we made any language change since 3.0 that would have required going through it so far.

I would say experimental in itself and the relevant policy of Snapshot/Nightly is a language change.
The latest export change is a language change.
IMO, the forward compatibility flags and new policy is a language change.

@smarter
Copy link
Member

smarter commented Feb 25, 2022

The whole point of experimental is to add things to the compiler before they've been accepted as official language changes so we can gain experience with them.

@soronpo
Copy link
Contributor Author

soronpo commented Feb 25, 2022

The whole point of experimental is to add things to the compiler before they've been accepted as official language changes so we can gain experience with them.

Of course, but that was a change to the language to allow that.

@dwijnand dwijnand marked this pull request as draft March 2, 2022 10:30
@odersky
Copy link
Contributor

odersky commented Mar 3, 2022

Seems some neg check files need to be updated.

@wjoel
Copy link
Contributor

wjoel commented Mar 3, 2022

My understanding is that the scala center is in the process of restarting the sip committee but I don't know what the timeline is. I don't think we made any language change since 3.0 that would have required going through it so far.

Since no meetings have been held since this post, I guess the list under "no concensus or no (closed) public discussion" in https://contributors.scala-lang.org/t/scala-3-feature-status-overview/4165/6 is somewhat accurate, and it includes a bunch of stuff which is already part of Scala 3 which probably would have been in the category of "required to go through SIP process"?

Including indentation syntax. If the SIP committee now wants to get involved in a tweak to that feature, as this is, well, ok, but please hurry instead of just blocking this because there will be some meetings at some point in the future (it sounds there's not even a date set, if you don't know the timeline to even begin).

@smarter
Copy link
Member

smarter commented Mar 3, 2022

Agreed, bu this should be discussed on https://contributors.scala-lang.org/, not here.

@soronpo
Copy link
Contributor Author

soronpo commented Mar 4, 2022

Seems some neg check files need to be updated.

The file tests\neg-custom-args\nowarn\nowarn.scala fails compilation due to syntax errors now. I don't understand why originally it did not fail:

@deprecated def f = 0
def t7a = f: @nowarn("cat=deprecation")
def t7b = f:
  @nowarn("msg=deprecated")
def t7c = f:          // warning (deprecation)
  @nowarn("msg=fish") // error (unused nowarn)

What is the meaning of f: before fewerBraces was enabled? This looks like code that shouldn't have compiled.
EDIT: OK, now reading it again, it's like foo: Type that was fixed in #14562. So there is still a problem now, and it looks like this will collide with fewerBraces.

@odersky
Copy link
Contributor

odersky commented Mar 4, 2022

It does collide, but I think that's OK. We cannot have a type ascription with a newline between a : and the next token anymore. I think we already special case where the type is the type of a val or def. I.e.

def f(x: A):
  B

should work. But that's as far as it goes. I don't think we can go further; the example in the test clearly has a different meaning under fewer braces. I also don't think we'll see code like this in the wild. If you must span several lines, then it should be done like this:

def t7b = f
  : @nowarn("msg=deprecated")

@soronpo
Copy link
Contributor Author

soronpo commented Mar 4, 2022

It does collide, but I think that's OK. We cannot have a type ascription with a newline between a : and the next token anymore. I think we already special case where the type is the type of a val or def. I.e.

def f(x: A):
  B

should work. But that's as far as it goes. I don't think we can go further; the example in the test clearly has a different meaning under fewer braces. I also don't think we'll see code like this in the wild. If you must span several lines, then it should be done like this:

def t7b = f
  : @nowarn("msg=deprecated")

OK, I'll update the test accordingly. I also doubt this kind of syntax exists in the wild, and even if it does, there shouldn't be a problem to update it to accommodate the fewerBraces rules.

@soronpo
Copy link
Contributor Author

soronpo commented Mar 4, 2022

It now fails with the following:

Error:  scala3-library-bootstrapped: Failed binary compatibility check against org.scala-lang:scala3-library_3:3.1.1! Found 2 potential problems (filtered 696)
Error:   * static field fewerBraces in object scala.runtime.stdLibPatches.language#experimental does not have a correspondent in current version
Error:     filter with: ProblemFilters.exclude[MissingFieldProblem]("scala.runtime.stdLibPatches.language#experimental.fewerBraces")
Error:   * object scala.runtime.stdLibPatches.language#experimental#fewerBraces does not have a correspondent in current version
Error:     filter with: ProblemFilters.exclude[MissingClassProblem]("scala.runtime.stdLibPatches.language$experimental$fewerBraces$")

Why are experimental flags part of the binary compatibility check?

@odersky
Copy link
Contributor

odersky commented Mar 4, 2022

I guess they shouldn't be. @dwijnand Do we need a Mima exclude, or would this work anyway in the next minor version?

@dwijnand
Copy link
Member

dwijnand commented Mar 4, 2022

If we annotate the scala.language.experimental object with the experimental annotation, and upgrade to mima 1.0.1, then we wouldn't need the exclusion. Retroactively add the annotation, which I hope was implied by the name! 😄

@soronpo
Copy link
Contributor Author

soronpo commented Mar 5, 2022

If we annotate the scala.language.experimental object with the experimental annotation, and upgrade to mima 1.0.1, then we wouldn't need the exclusion. Retroactively add the annotation, which I hope was implied by the name! 😄

Does this change need to happen in this PR or should I add Mima exclusions?

@dwijnand
Copy link
Member

dwijnand commented Mar 5, 2022

Exclusions are fine.

@anatoliykmetyuk anatoliykmetyuk modified the milestones: 3.2.0-RC1, 3.3.0-RC1 Apr 4, 2022
@jamesward
Copy link

I'd love to see this back in the 3.2 release.

@soronpo
Copy link
Contributor Author

soronpo commented Apr 25, 2022

Me too

@bishabosha
Copy link
Member

@hejfelix
Copy link

3.2 or bust! My body needs this 😉 😄

@julienrf
Copy link
Contributor

julienrf commented May 11, 2022

I know this is going to disappoint some people, but I think we should hold off this change and make it go through the SIP process (which should restart soon, but not in time for the 3.2.0 release, unfortunately).

@soronpo
Copy link
Contributor Author

soronpo commented May 11, 2022

@julienrf Is there an explanation why extension method language changes got merged without SIP approval and "fewerBraces" requires it?

@julienrf
Copy link
Contributor

@soronpo There were so many changes in Scala 3 that the Scala Improvement Process was not strictly followed otherwise that would have been too inefficient. The “short process” was described in this thread. In summary, while there was no proper proposal, those changes have still been discussed by the committee, and the community was also consulted (here).

That being said, what makes fewerBraces a little bit different from other features such as extension methods is that it may affect the code we write every day, in lots of places.

@soronpo
Copy link
Contributor Author

soronpo commented May 11, 2022

@julienrf I think you misunderstood my reference. I was referring to #14497 that enables export in extension methods, which was merged recently and is a NEW feature, whereas fewerBraces was discussed long ago during the fast-tracked Scala 3 change process.

@julienrf
Copy link
Contributor

julienrf commented May 11, 2022

Oh, that’s a good point. I see that Jamie has followed up in the meantime.

@hejfelix
Copy link

I know this is going to disappoint some people, but I think we should hold off this change and make it go through the SIP process (which should restart soon, but not in time for the 3.2.0 release, unfortunately).

makes sense, but shiny new, want now :D (I agree, however!)

@odersky
Copy link
Contributor

odersky commented May 23, 2022

I think we'll close for now, and will re-open when the SIP gives this a green light.

@odersky odersky closed this May 23, 2022
@Kordyjan Kordyjan changed the title Fewer braces are part of the language from 3.2.x Fewer braces are part of the language from 3.3.x Jun 4, 2022
@Kordyjan Kordyjan removed this from the 3.3.0-RC1 milestone Aug 2, 2023
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.