Allow `-_` and `+_` as type names for `-Xsource3` flag #2348

dos65 · 2021-05-18T12:20:31Z

Addresses #2347

scalameta/dialects/shared/src/main/scala/scala/meta/dialects/package.scala

scalameta/dialects/shared/src/main/scala/scala/meta/Dialect.scala

scalameta/parsers/shared/src/main/scala/scala/meta/internal/parsers/ScalametaParser.scala

scalameta/dialects/shared/src/main/scala/scala/meta/dialects/package.scala

kitbellew

sorry for butting in with yet another naming suggestion... @tgodzik @dos65 see if it makes more semantic (rather than syntactic) sense to you, as it did for me.

kitbellew · 2021-05-19T04:29:39Z

scalameta/dialects/shared/src/main/scala/scala/meta/Dialect.scala

+     * works under -Xsource3 flag
+     * https://github.com/scala/scala/pull/9605
+     */
+    val allowPlusMinusUnderscoreIdent: Boolean


I would rename this. Looking at the scala code and doc, I'd call this allowUnderscoreAsTypeWildcard and set to false in scala3 and scala2source3. the plus/minus thing is just a side effect because it needs co/contravariant types.

We already have allowTypeParamUndesrcore setting

so why not use it? this is how it is described:

// Dotty rejects placeholder as Type parameter val allowTypeParamUnderscore: Boolean,

yet it is never set to false anywhere and never used in parsing.

I agree that this one fits better.
But in this case non Source3 scala2 dialects will accept this new syntax too.
Also, I forgot that we also need to enable allowTypeParamUnderscore for scala3

@kitbellew @tgodzik are you ok with that?

Oh. allowTypeParamUnderscore is about different thing.

def f[_](a: Int): Int = ???

Ok, then the question is: are you ok to enable this syntax by default without any flag?

Oh. allowTypeParamUnderscore is about different thing.

def f[_](a: Int): Int = ???

Right, it's for a type parameter of a definition, not for a type definition. still, why can't i find any reads for allowTypeParamUnderscore, and never false for it?

Ok, then the question is: are you ok to enable this syntax by default without any flag?

allowUnderscoreAsTypeWildcard (or whatever you decide to call it) shouldn't be part of scala213.

i am thinking that we should implement some sort of reflection to allow a user to specify config

dialect { base = scala213 options { allowUnderscoreAsTypeWildcard = true } }

that way, we don't need to add it as part of any explicit dialect, we don't need scala213source3 either.

Right, it's for a type parameter of a definition, not for a type definition. still, why can't i find any reads for allowTypeParamUnderscore, and never false for it?

It's used in several places. For example - here

What about setting rename. I decided to keep the existing one.
I looked on it one more time and as we currently always parse _ as Type.Placeholder without any settings so the name you proposed doesn't fit for that.

What about setting rename. I decided to keep the existing one.
I looked on it one more time and as we currently always parse _ as Type.Placeholder without any settings so the name you proposed doesn't fit for that.

Perhaps I should have been clearer. My proposal (with wildcards) would have had the opposite value; i.e., if you [still] allow wildcards, then it will not be parsed with +/-.

kitbellew · 2021-05-19T04:37:13Z

scalameta/parsers/shared/src/main/scala/scala/meta/internal/parsers/ScalametaParser.scala

+          autoPos {
+            accept[Ident]
+            accept[Underscore]
+            Type.Name(s"${ident.value}_")


should Type.Placeholder be subclassed or supplemented with Type.CovariantPlaceholder and Type.ContravariantPlaceholder and used here? after all, +_ is closer to a placeholder than an identifier, no?

I thought about that. However, it's unclear if just a Name or Placeholder.
In Scala2 parser treat it as Name and then if kind-projector is enabled it might be transformed into Placeholder.

In Scala3 it will be Placeholder. Are there any cons of having Placeholder here?

meaning, ignore the covariance (since, according to @neko-kai, it will be inferred) and just pretend it was a simple _? maybe.

@kitbellew In Scala 3 yes. In Scala 2 the variance is meaningful – I believe Scalameta should treat these exactly as it currently treats +*/-*/+?/-? kind projector placeholders right now – regarding the latter, Scala 3's -Ykind-projector also treats +* and -* as if they're a simple _ as well – scala/scala3#12341

Currently, scalameta parses kind-projector syntax (+*/-*/+?/-?) just as Type.Name.
An additional thing here that we don't have variance mods for Type.Placeholder.

I think the best option here would be to turn +_, -_ into Type.Placeholder for Scala3 and keep them as Type.Name for Scala2*.

@kitbellew @tgodzik wdyt?

I think the best option here would be to turn +_, -_ into Type.Placeholder for Scala3 and keep them as Type.Name for Scala2*.

sounds good

tests/shared/src/test/scala/scala/meta/tests/parsers/TypeSuite.scala

kitbellew · 2021-05-19T04:39:06Z

scalameta/dialects/shared/src/main/scala/scala/meta/dialects/package.scala

@@ -152,6 +154,7 @@ package object dialects {
    .withAllowStarWildcardImport(true)
    .withAllowProcedureSyntax(false)
    .withAllowDoWhile(false)
+    .withAllowPlusMinusUnderscoreIdent(true)


should we start creating additional scala3 dialects? if we have lots of scala2.1x, why not scala3.1 and scala3.2?

We will most likely need to, but currently I am not sure what will be in 3.1 at this point.

we know that this flag we are adding is only in 3.2, right? at least according to the docs.

@kitbellew The new syntax is already available under a flag -Ykind-projector:underscores in 3.
See

https://docs.scala-lang.org/scala3/guides/migration/plugin-kind-projector.html

https://dotty.epfl.ch/docs/reference/changed-features/wildcards.html

3.2 is when underscores will become the default syntax for type lambdas, without any flags. (+_ and -_ however will still be guarded by a flag, because they do not make sense for new code, only for cross-compilation, because now variance is inferred)

for kind-projector that works under -Xsource3 flag.

dos65 · 2021-05-24T10:07:24Z

Summarizing all comments the final changeset is:

new flag allowPlusMinusUnderscoreAsIdent = true for Scala2*Source3
new flag allowPlusMinusUnderscoreAsPlaceholder = true for Scala3

tgodzik

LGTM!

kitbellew · 2021-05-24T11:40:28Z

scalameta/parsers/shared/src/main/scala/scala/meta/internal/parsers/ScalametaParser.scala

+            if (dialect.allowPlusMinusUnderscoreAsPlaceholder)
+              Type.Placeholder(typeBounds())
+            else
+              Type.Name(s"${ident.value}_")


does this version not allow type bounds?

yep, but it is in line with scala/scala#9605

dos65 commented May 18, 2021

View reviewed changes

scalameta/dialects/shared/src/main/scala/scala/meta/dialects/package.scala Outdated Show resolved Hide resolved

dos65 force-pushed the kind-projector-source3 branch from 3aabc5f to a6dc868 Compare May 18, 2021 12:34

tgodzik requested changes May 18, 2021

View reviewed changes

dos65 force-pushed the kind-projector-source3 branch 3 times, most recently from 1c3bbdf to 05c354a Compare May 18, 2021 17:28

kitbellew reviewed May 19, 2021

View reviewed changes

dos65 force-pushed the kind-projector-source3 branch from 05c354a to d5fc267 Compare May 24, 2021 08:33

Allow -_ and +_ as type names in order to support lastest changes

55606a8

for kind-projector that works under -Xsource3 flag.

dos65 force-pushed the kind-projector-source3 branch from d5fc267 to 55606a8 Compare May 24, 2021 09:22

dos65 requested review from tgodzik and kitbellew May 24, 2021 10:07

tgodzik approved these changes May 24, 2021

View reviewed changes

kitbellew reviewed May 24, 2021

View reviewed changes

dos65 merged commit b9bd51b into scalameta:main May 24, 2021

dos65 deleted the kind-projector-source3 branch May 24, 2021 13:19

neko-kai mentioned this pull request May 31, 2021

Spurious space inserted in +_/-_ type lambdas scalameta/scalafmt#2560

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Allow `-_` and `+_` as type names for `-Xsource3` flag #2348

Allow `-_` and `+_` as type names for `-Xsource3` flag #2348

dos65 commented May 18, 2021

kitbellew left a comment

kitbellew May 19, 2021

dos65 May 19, 2021

kitbellew May 19, 2021

dos65 May 20, 2021

dos65 May 20, 2021

kitbellew May 20, 2021

dos65 May 24, 2021

kitbellew May 24, 2021

kitbellew May 19, 2021

dos65 May 19, 2021

kitbellew May 19, 2021

neko-kai May 19, 2021 •

edited

dos65 May 20, 2021

kitbellew May 20, 2021

tgodzik May 21, 2021

kitbellew May 19, 2021

tgodzik May 19, 2021

kitbellew May 19, 2021

neko-kai May 19, 2021

neko-kai May 19, 2021

dos65 commented May 24, 2021

tgodzik left a comment

kitbellew May 24, 2021

dos65 May 24, 2021

Allow -_ and +_ as type names for -Xsource3 flag #2348

Allow -_ and +_ as type names for -Xsource3 flag #2348

Conversation

dos65 commented May 18, 2021

kitbellew left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

neko-kai May 19, 2021 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dos65 commented May 24, 2021

tgodzik left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Allow `-_` and `+_` as type names for `-Xsource3` flag #2348

Allow `-_` and `+_` as type names for `-Xsource3` flag #2348

neko-kai May 19, 2021 •

edited