Change wildcard given selectors #9949
Conversation
Implements a syntax change for wildcard imports.
Instead of
```scala
import p.{given _}
```
write
```scala
import p.given
```
The same applies for wildcard given imports in braces: `given _` is contracted to just `given`. Given-by-type imports remain unaffected: It's still
```scala
import p.{given T}
```
for those.
The rationale is that we should not make it needlessly hard to write wildcard given imports. The additional underscore after a `given` is not needed for disambiguation and clutters the code.
|
For now, both old and new syntax are supported. If this PR is merged, the old |
|
The only downside is that someone will have to adjust the StackOverflow answer for "how many uses of underscore are there in Scala 3?" Arguably the syntax could have been |
| if in.token == USCORE then | ||
| in.nextToken() | ||
| ImportSelector(givenSelector()) // Let the selector span all of `given _`; needed for -Ytest-pickler | ||
| ImportSelector(givenSelectorId(start)) // Let the selector span all of `given _`; needed for -Ytest-pickler |
There was a problem hiding this comment.
Is this code path still needed for compatibility? If so, should we issue a deprecation warning here?
There was a problem hiding this comment.
So, far, we were changing syntax without warnings. But maybe we should change that now...
There was a problem hiding this comment.
I tried to deprecate but that does not work for the current cycle since we still use given _ in bootstrap code. So we could deprecate at the earliest once 3.0 M1 is released. Or we just rip off the bandaid and disallow it altogether for M2.
There was a problem hiding this comment.
We can do a bootstrap before M1 is released (and we probably should do one to make sure everything works OK with the new naming scheme)
There was a problem hiding this comment.
OK. We can deprecate again once that's done
|
@som-snytt already rejected alas... #8696 |
`given ?` is not well-formed, since given Anyas an alternative to just |
This reverts commit 099074c.
|
I'm probably late to the party, but to me import given p.T, p.MyType
import given p._, q._No need to repeat |
|
Is given a hard keyword? If not how do I import something named given?
Would this change require adding backticks?
…On Wed, Oct 7, 2020, 7:19 PM Sakib Hadžiavdić ***@***.***> wrote:
I'm probably late to the party, but to me import p.given looks like I'm
importing a member called given..
Wouldn't it be more intuitive to do similar to java's import static Abc.*?
E.g.
import given p.T, p.MyTypeimport given p._, q._
No need to repeat given, given .. for every argument.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#9949 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAYAUDYFVYYAF7CWZTBO53SJTZR7ANCNFSM4SFXWE4A>
.
|
|
@sake92 if by late to the party you mean arriving just as drunken revelers stumble down the sidewalk discussing whether to deprecate first, then yes, pretty late. It began innocently with a few cocktails at https://contributors.scala-lang.org/t/proposed-syntax-change-import-given/4547 |
Was superceded by `given` in scala#9949.
Was superceded by `given` in scala#9949.
Implements a syntax change for wildcard imports.
Instead of
write
The same applies for wildcard given imports in braces:
given _is contracted to justgiven. Given-by-type imports remain unaffected: It's stillfor those.
The rationale is that we should not make it needlessly hard to write wildcard given imports. The additional underscore after a
givenis not needed for disambiguation and clutters the code.