Type named $ is replaced by empty string in error messages

[TomasMikula]

Compiler version

3.1.3-RC2

Minimized code

case class $[A](value: A)

def f(x: Int): Unit = {}

f(T(3))

Output

Found:   [Int]
Required: Int

Notice the missing $.

Expectation

Found:    $[Int]
Required: Int

[nicolasstucki]

Names with $ are reserved for compiler internal use by the language specification, their usage in user code has undefined behavior. Therefore this is not a bug.

[nicolasstucki]

We could still try to print the $ anyway

[Florian3k]

I've tried to debug this. Trailing $ are being removed by RefinedPrinter.nameString:

override def nameString(name: Name): String =
  def strippedName = if printDebug then name else name.stripModuleClassSuffix
  ...

I understand that this is desired behaviour, because we want do display compiler-generated names without trailing dollars. I don't see any easy way to distinguish between user provided names and those generated by compiler.

Potentially, we could add field to Name indicating whether it's coming from source code or not, but I suspect that this will require significant changes. Since using $ inside names is undefined behaviour, I don't think making such changes is desirable.

[TomasMikula]

Why then allow $ in source names at all? There should be some consistency.

[som-snytt]

stripModuleClassSuffix should not strip the bare $, a suffix which is also a prefix. Clearly an empty name is wrong.

$ is not forbidden because we all need to do some Java interop on occasion; also some Scala interop. One might refer to A$B in tooling.

[Florian3k]

This problem exists with any name ending with $, example:

case class T$[A](value: A)

def f(x: Int): Unit = {}

@main def main = f(T$(3))

Output:

5 |@main def main = f(T$(3))
  |                   ^^^^^
  |                   Found:    T[Int]
  |                   Required: Int
  |
  | longer explanation available when compiling with `-explain`

[som-snytt]

There are perverse usages of $, which must run afoul of internal conventions, and possibly reasonable usages, such as a regex library that wants to name something $. Or a monetary unit called $.

It might be useful to add a FAQ about these edges.

[nicolasstucki]

case class T$[A](value: A)

Will not compile correctly, the class T$ will conflict with the class of the companion object with the same name. One will override the other. This behavior is consistent with the undefined behavior of names using $.

[nicolasstucki]

The best thing we could do is to identify names containing $ and emit a warning. Most users do not know that these names are reserved for compiler generated code.

[som-snytt]

I don't know about the best thing.

This does the right thing for innocent $: #15597

I probably would not write object syntax { object $ }.

[jducoeur]

So, I do have a real world example that is used a fair amount, albeit not a JVM one: the jquery-facade library that I wrote for the Scala.js ecosystem: https://github.com/jducoeur/jquery-facade That uses '$' quite heavily, because it is trying to closely mimic the underlying jQuery library that it wraps around - this allows us to leverage the existing documentation and ecosystem with as little surprise as possible. (jQuery used to be perhaps the most important JavaScript library; it has lost a lot of ground, but is still moderately popular.)

…

On Wed, Jul 6, 2022, 1:11 AM som-snytt ***@***.***> wrote: I don't know about the best thing. This does the right thing for innocent $: #15597 <#15597> I probably would not write object syntax { object $ }. — Reply to this email directly, view it on GitHub <#15381 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAQVNYKN552D2KHDAOXAGTDVSUIRHANCNFSM5X5RGUCA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[nicolasstucki]

The authors or maintainers of jQuery wrapper library have been told many years ago that their use of the $ can hit undefined behavior. The simple fix for them is to use `$` instead.

[som-snytt]

A backquoted identifier is usually just an identifier. The famous exception is it's not a pattern varid. The recent exception is it's not a unary prefix operator. Backquotes also change syntax for leading infix operators: instead of an exclusion, it lets a non-symbolic identifier "opt in" as leading infix.

Backquotes don't have uniform semantics, but are more like variance: add backquotes until it compiles. If the language had adopted guillemets, there would be more quotes to try before giving up.

Of course, autocorrect just changed guillemets to guillemots, which is the bird even though mot means word. Worth acknowledging that the Mets baseball team is having a pretty good year.

[som-snytt]

The issue about accessing Scala MODULE$ from Java makes me think messages should never strip dollar in a Java context.

7 |import bar.slf4j.ScalaMDCAdapter$;
  |                 ^
  |                 value ScalaMDCAdapter is not a member of bar.slf4j - did you mean slf4j.ScalaMDCAdapter?

#15608

[Billal-B]

It appears to be working :

case class $[A](value: A)

def f(x: Int): Unit = {}

val x = f($(3))

Error output :

-- [E007] Type Mismatch Error: /home/billal/Projects/foss/dotty_playground/15381/15381.scala:5:11 
5 |val x = f($(3))
  |          ^^^^
  |          Found:    $[Int]
  |          Required: Int
  |
  | longer explanation available when compiling with `-explain`

See test added by the following commit : b5203de

[anatoliykmetyuk]

Found and closed during the Scala spree at ScalaIO 2022 - thanks @Billal-B for spotting!

[som-snytt]

My previous comment may have been why I thought it might not be closed #15381 (comment)