Parsing inconsistency of def vs. given with structural refinement

[TomasMikula]

Compiler version

3.6.4

Minimized code

class Foo { type T }

// `def` works fine
def foo[A]: Foo { type T = A } =
  new Foo { type T = A }

// `given` does not: Syntax error: 'with' expected, but '{' found
given bar[A]: Foo { type T = A } =
  new Foo { type T = A }

// workaround: add parentheses
given baz[A]: (Foo { type T = A }) =
  new Foo { type T = A }

Output

-- [E040] Syntax Error: Test.scala:8:18 ----------------------------------------
8 |given bar[A]: Foo { type T = A } =
  |                  ^
  |                  'with' expected, but '{' found
-- [E040] Syntax Error: Test.scala:14:0 ----------------------------------------
14 |
   |^
   |'}' expected, but eof found
2 errors found

Expectation

I would expect def and given syntax to be consistent as much as possible.

[som-snytt]

Parens are required for new syntax which is less def-like.

given [A] => (Foo { type T = A }) = new Foo { type T = A }

[TomasMikula]

Parens are required for new syntax which is less def-like.

given [A] => (Foo { type T = A }) = new Foo { type T = A }

This syntax is analogous to polymorphic functions, but there, parens are not required either:

class Foo { type T }

// works without parens
val foo: [A] => DummyImplicit ?=> Foo { type T = A } = 
  [A] => _ ?=> new Foo { type T = A }

[Gedochao]

As noted by @som-snytt, this works as intended. The parens are required for this syntax.
Closing this.

[TomasMikula]

@Gedochao @som-snytt When you say "parens are required", are you referring to a deliberate design (in that case, can you please link it here?), or just stating a fact about the current parser behavior?

[som-snytt]

Yeah I was just noting the fact, not endorsing. I took a look at the syntax page; it might be just an artifact of old syntax. GivenType looks innocuous. I'll spend some time with it today and either reopen or add an explanation here.

[som-snytt]

Now I know why I tend to use given T = expr syntax; it's because I didn't understand the syntax.

The example is redundant. The syntax friction is not due to old syntax but the two RHS of GivenImpl production.

I didn't yet look at whether the parser could easily recover when it sees the = (indicating which RHS is intended).

The context dependency is because type Foo could be ctor Foo(). (I recently learned that Scala 3 is OK when traits receive extraneous parens, so lax parens are deeply engrained.)

There is a difference whether you get a given_Foo class or the anon class is local to the given def, so it's not just syntax.

class Foo { type T }

//given [A] => (Foo { type T = A }) = new Foo { type T = A } // are parens really needed

//given conditional => given sig
// => given impl
// => given type = expr
// or
// => constrapps template body
// i.e. C() with D() { } or C, D { }

//given [A] => Foo { type T = A } = new Foo { type T = A }  // parens needed
given [A] => Foo { type T = A }
//given [A] => Foo = new Foo { type T = A } // for comparison
//given thing: [A] => Foo { type T = A } // name it just by putting a name in front

def f(using Foo) = ()
def g = f

[som-snytt]

The reference (since my contribution last June) no longer advertises

given IntOrd, Ops[Int]

which previously required parens (said my previous contribution), but not since the new syntax.

I saw discussion about whether or how to support defining anonymous classes without with and whether comma is best.

That makes me wonder if given X, Y syntax is about to be softly deprecated. The nomenclature is still "alias given" if there's an equals, "structural given" otherwise. I think "structural" means "regular", but possibly the alias syntax was worked out first, but sorting out colons and withs took longer.

Maybe further syntax tweaks will obviate the inconsistency reported here.