"Double definition:" error for `given`s isn't helpful

[mr-git]

Compiler version

3.7.2

Minimized code

//> using scala 3.7.2
trait Special[A]

object syntax:
  given Special[Option[Long]] = ???
  given Special[Option[Int]] = ???

Output

-- [E120] Naming Error: --------------------------------------------------------
3 |  given Special[Option[Int]] = ???
  |        ^
  |Double definition:
  |final lazy given val given_Special_Option: Special[Option[Long]] in object syntax at line 2 and
  |final lazy given val given_Special_Option: Special[Option[Int]] in object syntax at line 3
1 error found

Why this Error/Warning was not helpful

The error says what is wrong, but doesn't mention that it is due to design decision in Scala 3 compiler nor provides a workaround, not even with "-explain-types" flag. It leaves user with no help and user might introduce extra objects to put givens in different scopes.

Suggested improvement

As per #23831, the "short names" are by design, and expected solution is to use @targetName("xxx") annotations.

It could be made more helpful if error message would explicitly suggest to use @targetName annotations for custom name provisions.

[som-snytt]

The reference says

The name of a given can be left out.

That implies that the name of a given can also be left in.

It wouldn't hurt if the message said, "Did you try naming your givens?"

The number of tickets in this area indicates the need for an improvement of some kind.

(The clash also happens for local givens, which could be given a fresh name, since there is no expectation of stability; however, that is probably a problem no one has, and is inconsistent with being able to rely on using the default name.)

(You can't write given _: Option[List[String]] as you can with val _: ... to get val _$1: Option[List[String]] =.)

[som-snytt]

The reason it rings a bell is that now it says (with -explain):

-- [E120] Naming Error: /home/amarki/projects/scala3/tests/neg/i23832.scala:7:8
7 |  given Special[Option[Int]] = ??? // error
  |        ^
  |Conflicting definitions:
  |final lazy given val given_Special_Option: Special[Option[Long]] in object syntax at line 6 and
  |final lazy given val given_Special_Option: Special[Option[Int]] in object syntax at line 7
  |-----------------------------------------------------------------------------
  | Explanation (enabled by `-explain`)
  |- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  |
  | As part of the Scala compilation pipeline every type is reduced to its erased
  | (runtime) form. In this phase, among other transformations, generic parameters
  | disappear and separate parameter-list boundaries are flattened.
  |
  | For example, both `f[T](x: T)(y: String): Unit` and `f(x: Any, z: String): Unit`
  | erase to the same runtime signature `f(x: Object, y: String): Unit`. Note that
  | parameter names are irrelevant.
  |
  | In your code the two declarations
  |
  |   final lazy given val given_Special_Option: Special[Option[Long]]
  |   final lazy given val given_Special_Option: Special[Option[Int]]
  |
  | erase to the identical signature
  |
  |   Special
  |
  | so the compiler cannot keep both: the generated bytecode symbols would collide.
  |
  | To fix this error, you need to disambiguate the two definitions. You can either:
  |
  | 1. Rename one of the definitions, or
  | 2. Keep the same names in source but give one definition a distinct
  |    bytecode-level name via `@targetName` for example:
  |
  |       @targetName("given_Special_Option_2")
  |       final lazy given val given_Special_Option: Special[Option[Int]]
  |
  | Choose the `@targetName` argument carefully: it is the name that will be used
  | when calling the method externally, so it should be unique and descriptive.
  |
   -----------------------------------------------------------------------------
1 error found

Anonymous givens are such an important use case, however, that probably the end of the explainer could be tweaked to cover it.

The syntax of givens is understandably not fresh in everyone's mind.

[mr-git]

about:

now it says (with -explain)

where or when is now? is it in some 3.8.0-nightly? In 3.7.2 the -explain provides no hints or suggestions.

[som-snytt]

@mr-git since a month or so ago in nightly. I haven't checked for backports: features can wind up on LTS (3.3.x).

It also says what was backported to 3.7.3 (which is still RC).

The scala-cli syntax is -S 3.nightly to test the latest. Not sure if 3.7.3.nightly or similar works.

[Gedochao]

It's also worth noting that Scala 3 nightlies have been moved to a new repo, and Scala CLI does not support it just yet.
https://repo.scala-lang.org/

The change is on a PR (waiting for CI) to merge it:

• Add support for the new Scala 3 nightly repository VirtusLab/scala-cli#3838

So at the moment, Scala CLI refers to nightlies up to the point the change occurred. You'll need to upgrade to the newest CLI to get the new stuff (when I release it) or use the CLI nightly (--cli-version nightly)

Not sure if 3.7.3.nightly or similar works.

3.7.3.nightly doesn't, but 3.7.nightly does. (major.nightly or major.minor.nightly, as a rule)