Trait parameters are not abstract when Scala.js inspects them

[bishabosha]

Compiler version

3.0.0

Minimized code

import scala.scalajs.js
import scala.scalajs.js.annotation.*

object A {

  @js.native
  trait Bag extends js.Any {
    val str: String
  }

  trait NonNativeBagHolderTrait(val bag: Bag) extends js.Any // error

}

Output

-- Error: tests/neg-scalajs/js-native-exports.scala:11:36 --------------------------------------------------------------
11 |  trait NonNativeBagHolderTrait(val bag: Bag) extends js.Any // error
                                ^^^^^^^^^^^^
       Members of non-native JS traits must either be abstract, or their right-hand-side must be `js.undefined`.

Expectation

no error, like if val bag: Bag is moved from trait params to the body

[sjrd]

It's not the same in terms of compilation if they are moved to the body, though, is it? I'm not sure it would make sense from the perspective of semantics of JS types. JS traits are supposed to be pure interfaces without any implementation.

[anatoliykmetyuk]

Does it introduce a regression compared to Scala 2 Scala.js? @sjrd does your comment mean we can close this?

[sjrd]

Scala 2 doesn't have trait parameters, so definitely not a regression.

Reporting an error is the correct thing to do. That said, the error message could be improved, saying something like "JS traits cannot have parameters" or something like that.

[bishabosha]

if I compile this similar example

object A {

  trait Bag extends Any {
    val str: String
  }

  trait TraitWithParam(val bag: Bag) extends Any


  trait StdTrait extends Any {
    val bag: Bag
  }

  val b: Bag = new { val str = "hello" }

  class Foo extends TraitWithParam(b)
  class Bar extends StdTrait {
    val bag = b
  }

}

then both Foo and Bar look identical after mixin phase - so is the issue that effectively you must provide an implementation for the bag field?

[bishabosha]

conceptually, parameters are concrete members so they should be disallowed, but we can special case the error message here