Will it also work for self types?

trait Foo: self =>
end Foo

I wonder if xs.map: case Some(x) => x + 1 could be made to work as well?

The case for case is at #22016. I think the parens SIP opens the floodgates of consistency.

If we need a SIP for this, maybe we could fold it into https://contributors.scala-lang.org/t/sip-xx-allow-partial-function-literals-to-be-defined-with-parentheses/7207/16

if we need a SIP for this, maybe we could fold it into https://contributors.scala-lang.org/t/sip-xx-allow-partial-function-literals-to-be-defined-with-parentheses/7207/16

Yes, I think the two go well together. This PR now also implements the single-case version of sip-xx. I have some reservations against admitting multiple cases between parentheses. I'll explain more on the SIP.

Will it also work for self types?

Right now, no. I'd like to re-think self types in general. So I'm not keen on fiddling with them until that's done.

Awesome. Will this extend to lambdas with by-name parameters and/or context parameters?

You can currently write

// after delay, execute fn
def delay(ms: Double)(fn: => Unit) = ???

delay(300):
  println("hello")

Will we also be able to write

def delay(ms: Double)(fn: => Unit) = ???

delay(300): println("hello")

and

def delay(ms: Double)(fn: (timestamp : Double) ?=> Unit) = ???

delay(300): println(s"time ${timestamp}")

?

Awesome. Will this extend to lambdas with by-name parameters and/or context parameters?

Currently, no. We should discuss what we want. Some choices:

1. no extension to by-name or context-parameters
2. allow : syntax for these parameters only
3. allow : syntax for all arguments.

Possible reason for (2): The situation is similar to single-line-lambdas with parameters.
Possible reason for (3): We don't distincguish syntactically between by-name and by-value elsewhere.

If we allow delay(300): println("hello"), wouldn't we then have to allow println: "hello", and wouldn't println: "hello" be indistinguishable from a type ascription?

If we allow delay(300): println("hello"), wouldn't we then have to allow println: "hello", and wouldn't println: "hello" be indistinguishable from a type ascription?

Sorry I might be missing something, why would we have to allow println: "hello"? I was under the impression that : would only trigger an attempt to interpret the following rhs as a lambda when the parameter is typed as such? I assume that's what Martin meant by option 2?

Sure, println is not a higher order function, and delay(300): is. But do you know that information during parsing? Because this distinction between "this is a type ascription" and "this is a function taking a code block on the right" needs to happen super early even before typechecking happens.

If you don't like println, how about delay(300): "hello": is this a function call with a type ascription, or a function call taking two parameter lists?

@lihaoyi Yes, indeed. Allowing arbitrary expressions after: would conflict with type ascriptions. So I think we need to bury the idea.

I believe we have a problem with the new build. It does not pick up the scala-library changes in the bootstrapped build.
I see:

-- [E008] Not Found Error: tests/pos/closure-args.scala:1:29 -----------------------------------------------------------
1 |import language.experimental.relaxedLambdaSyntax
  |                             ^^^^^^^^^^^^^^^^^^^
  |                             value relaxedLambdaSyntax is not a member of object language.experimental

Yet, relaxedLambdaSyntax was added to language.experimental in the commit.

This was accepted as ready or implementation in the SIP meeting of Oct 24th, 2025.

No new regressions found in the OpenCB when comparing against current main