"is not a class type" error for given for intersection type

[user753]

Compiler version

3.1.0

Minimized example

trait Foo:
  def foo: Int

trait Bar:
  def bar: Int  

given (Foo & Bar) with
  def foo = 1
  def bar = 2

Output

compilation error

Foo & Bar is not a class type

Expectation

I think something like

Intersection type cannot be used with given

would be clearer

[som-snytt]

Or, say, "Did you mean...?" and tell us what to write.

One imagines a session like the following.

As a footnote, error recovery on missing with is a bit wonky.

scala> def f(using x: AutoCloseable & Runnable) = try x.run() finally x.close()
def f(using x: AutoCloseable & Runnable): Unit

scala> f
-- Error:
1 |f
  | ^
  | no implicit argument of type AutoCloseable & Runnable was found for parameter x of method f

scala> given AutoCloseable & Runnable with { def close() = () }
-- Error:
1 |given AutoCloseable & Runnable with { def close() = () }
  |                    ^
  |                    'with' expected, but identifier found
-- Error:
1 |given AutoCloseable & Runnable with { def close() = () }
  |                                                        ^
  |                                                        '{' expected, but eof found

scala> given (AutoCloseable & Runnable) with { def close() = () }
-- Error:
1 |given (AutoCloseable & Runnable) with { def close() = () }
  |      ^^^^^^^^^^^^^^^^^^^^^^^^^^
  |      AutoCloseable & Runnable is not a class type

scala> given AutoCloseable with Runnable with { def close() = () ; def run() = () }
// defined object given_AutoCloseable_Runnable

scala> given AutoCloseable { def close() = () }
-- Error:
1 |given AutoCloseable { def close() = () }
  |                    ^
  |                    'with' expected, but '{' found
-- Error:
1 |given AutoCloseable { def close() = () }
  |                                        ^
  |                                        '{' expected, but eof found

[user753]

So It's possible to do this

given Foo with Bar with 
  def foo = 1
  def bar = 2

So I am not sure what is the problem with given Foo & Bar?

[som-snytt]

Probably because you have to construct an instance. A & B is not the same as A with B because of linearization, where order matters.

scala> trait T { def f: Int = 42 }
// defined trait T

scala> trait U { def f: Int = 27 }
// defined trait U

scala> class C extends T, U { override def f = super.f } ; C().f
// defined class C
val res0: Int = 27

scala> class C extends U, T { override def f = super.f } ; C().f
// defined class C
val res1: Int = 42

That reminds me, I don't remember where I noticed withless syntax.

[user753]

A & B is not the same as A with B because of linearization, where order matters.

Yes, but given Foo with Bar can be used for using Foo & Bar

given Foo with Bar with 
  def foo = 1
  def bar = 2

def fooBar(using fb: Foo & Bar) = fb.foo + fb.bar  

println(fooBar) // 3

[som-snytt]

I meant to say that & is commutative but with is not. Foo with Bar is both Foo & Bar and Bar & Foo, but not the same as Bar with Foo; that is my guess why with is required here.

I forgot to add that comma is not a synonym for with in the type of a given:

scala> given AutoCloseable, Runnable with { def close() = () ; def run() = () }
-- Error:
1 |given AutoCloseable, Runnable with { def close() = () ; def run() = () }
  |                   ^
  |                   'with' expected, but ',' found
-- Error:
1 |given AutoCloseable, Runnable with { def close() = () ; def run() = () }
  |                                                                        ^
  |                                                                        '{' expected, but eof found

While browsing the repo, I saw an old comment about disallowing with in anonymous classes, so you could only have one parent, IIRC. So I don't know what their intentions are.

[bishabosha]

The difference here is that intersection types can only be the types of return values, or parameters - a given <type> with ... is similar to a class declaration, so can not use an intersection type. If you would like an intersection type then you need an alias given : given <type> = ...

[nicolasstucki]

We sould probably add a -explain to NotClassType in messages.scala.

[scala-center-bot]

This issue was picked for the Issue Spree No. 42 of February 6th, 2024. @SethTisue, @spavikevik, @iusildra, @aherlihy will be working on it. If you have any insight into the issue or guidance on how to fix it, please leave it here.

[SethTisue]

"Class type" is spec language that is not familiar to most Scala programmers. So we must either avoid it, or explain it.

[SethTisue]

We have been discussing whether it's enough to change and/or add an "-explain" text to the general error message, or whether it's worth trying to make it specific to the given case. None of us feel strongly that it's worth doing something specific for given.

It would be nice to avoid the term "class type", but we can't think of a concise alternative, so I guess we'll just add an "explain" text.

We weren't sure initially how many other situations this error might come up in. It appears to us that the three main non-class types are intersection types, union types, and refinement types. (In Scala 2, only two error messages refer to "class type", and both appear intended to only exclude refinement types.)