Decide what future behavior should be enabled in 3.4

[bishabosha]

for -source:3.4 we need to turn on current future semantics for refutable pattern bindings

[odersky]

In fact, now is the time to look at all future features to see which ones we want to enable in 3.3

[odersky]

I see the following occurrences of future in the compiler. We should discuss a which ones we want to move to 3.3.
My main guideline for recommendations was that we want to still be able to cross-compile with 2.13.

Refutable patterns

Make it an error if in

 val p = e

or

 for p <- g

the pattern p is refutable pattern. Right now it is a warning.

scala> val xss = List(List(1, 2, 3), Nil)
val xss: List[List[Int]] = List(List(1, 2, 3), List())
                                                                                                                      
scala> for x :: _ <- xss do println(x)
1
1 warning found
-- Warning: --------------------------------------------------------------------
1 |for x :: _ <- xss do println(x)
  |    ^^^^^^
  |pattern's type ::[Int] is more specialized than the right hand side expression's type List[Int]
  |
  |If the narrowing is intentional, this can be communicated by adding the `case` keyword before the full pattern,
  |which will result in a filtering for expression (using `withFilter`).

Recommendation: ? We can enable it if there is a way to cross compile to 2.13. For val's this is the case, but I am not sure about the for expression case? Can we write for case p <- xs in 2.13?

Wildcard Arguments

Drop _ for wildcard arguments of types. use ? instead.

I.e. use List[?] instead of List[_].

Recommendation: ?

Deprecate type tests using ClassTag

Warn if a type test on an abstract type in a pattern match is performed with a ClassTag. Demand a TypeTest instead.

Recommendation: ?

Context Parameters

Make context parameters using clauses instead of implicit parameters. This changes the behavior of explicitly passed arguments to context parameters. I think we need to keep the old behavior for now, so that we can continue to cross compile between 3.3 and 2.13. The time to change this is after the LTS.

Recommendation: wait

Overriding of Val Parameters

Disallow overriding of Val parameters. Right now it gives a deprecation warning. Since we only established the restriction recently, it looks like we have to wait a bit longer to enforce it.

Recommendation: wait

Symbol Literals

Drop deprecated symbol literals altogether.

Recommendation: wait

Drop old Varargs syntax

Drop xs: _* for varargs. Use xs* instead.

Recommendation: wait

Deprecate private/protected[this]

Deprecate private[this] and protected[this]

Recommendation: ?

Deprecate old import syntax

• Deprecate _ as an import wildcard, demand import x.* instead.
• Deprecate a => b for renaming imports, demand a as b instead.

Recommendation: wait

Deprecate old uninitialized variable syntax

Deprecate var x = _, demand var x = uninitialized instead.

Recommendation: wait

Remove non-local returns

They currently produce warnings

Recommendation: wait

Ad-hoc extensions

Demand an adHocExtensions language import if a class that is not abstract or open is extended in another compilation unit.

Recommendation: wait

Trailing underscore function syntax

Drop the f _ syntax that forces eta expansion

Recommendation: wait

[smarter]

Can we write for case p <- xs in 2.13?

Yes, this is possible in both 2.12 and 2.13 now, case is just a no-op by default: scala/scala#9721

[carlosedp]

I was looking for a way to directly unpack tuples on for comprehensions and found better-monadic-for then saw that enabling the -source:future flag makes the behavior available in Scala 3. One use case is similar to zio/zio#2761.

I wonder if there plans to make it available as default in Scala 3.3 without the flag?

[gabro]

Hi, just FYI the documentation still states that the new pattern bindings behavior "will be enabled by default in version 3.2 of the language", which turns out not to be true.

I can send a PR updating the docs, but I was wondering if there's a scheduled timeline for this?

[smarter]

Ideally 3.4, there's now a thread on contributors on the subject: https://contributors.scala-lang.org/t/make-tuple-unpack-feature-from-source-future-become-default/6238

[odersky]

There's no scheduled timeline. It would be great if someone would work out a proposition.

[carlosedp]

I understand the implementation already exists in dotty and it would be a matter of making it into 3.4 instead of source:future, correct?

If so, I could take a look into trying to submit a PR changing this.

[bishabosha]

I've now updated the title to be what to enable in 3.4

[SethTisue]

I have taken the liberty of adding this to the 3.4.0 milestone.

[rssh]

Also, please look at making -XmacroSettings non-experimental.
(related ticked - #15637 )

[nicolasstucki]

-XmacroSettings is not ready to be made non experimental. We do not have a proper specification for it and we know that the current implementation is fundamentally broken.

[carlosedp]

I've submitted #18606 to address the direct tuple assignment in for comprehensions.

[nicolasstucki]

We decided to include in 3.4 all that is already on maser plus what is listed in the 3.4 milestone. The list of syntactic deprecation warnings that will be enabled in 3.4 can be found here.

[joan38]

This does not seem enabled in Scala 3.4.x
See Stackoverflow question https://stackoverflow.com/questions/78580466/why-doesnt-my-scalac-prints-any-warning-for-missing-open-keyword
Any information on if it is and we are missing something or if it's planned for 3.5.x?

[odersky]

3.5 is already defined, but it should arrive in 3.6, later this year. It is already enabled under -source future.