`[E008] Not Found Error:` fails due to clashing names, but doesn't mention it, nor provides suggestion on how to workaround

[mr-git]

Compiler version

3.7.2

Minimized code

//> using scala 3.7.2
import java.nio.charset.StandardCharsets

object syntax: // works (1) if `extension` is moved inside `object Complex` in place of `import syntax.*`
  extension (self: String)
    def bytes: Int = self.getBytes(StandardCharsets.UTF_8).length

final case class Complex(name: String)

object Complex:
  val one = Complex("1")
  import syntax.* // works (1) if `extension`(s) from `syntax` are moved here
  extension (self: Complex)
    // works (2) if name doesn't clash with imported function's name `bytes`, for example `bytes1` is OK
    def bytes: Long = self.name.bytes

import Complex.*
@main def test =
  println(s"size of `Complex`: ${one.bytes}")

Output

-- [E008] Not Found Error: -----------------------------------------------------
8 |    def bytes: Long = self.name.bytes
  |                      ^^^^^^^^^^^^^^^
  |        value bytes is not a member of String.
  |        An extension method was tried, but could not be fully constructed:
  |
  |            Complex.bytes(self.name)
  |
  |            failed with:
  |
  |                Found:    (self.name : String)
  |                Required: Complex
1 error found

Expectation

If compiler found clashing names, in error message with -explain it could suggest to change import syntax.* to given syntax.type = syntax (or the dangerous case given goodies: syntax() from #23830).

[mr-git]

The second rule is not obvious, specially after many years importing Scala 2.13 implicits.

Very strange, that there is dedicated section for Importing Givens, but for extensions there is long-ish chapter "Translation of Calls to Extension Methods", which doesn't even mention import 😞

[som-snytt]

This ticket duplicates the conjecture on the tickets about "extension will never be used" warning, that a better but more expensive warning would warn at the use site that an extension (somewhere) was not used for the selection.

That would be typically because in a.b, a already has the member. (Maybe it was added since the extension was coded.)

In this ticket, the extension is "nullified" for a different reason.

I assume (without evidence) that such a warning is too expensive (because it warns about successful code), but maybe it's worth it for erroring code, much like import suggestions.

The long bullet item about importing extensions begins:

If m is imported by several imports which are all on the nesting level...

That feature was added later after lobbying by prominent community members, so I think that is why it is not foregrounded in the reference. A hypothetical document for new users about "How should I structure my extensions?" would probably make special notice of it.

By contrast, importing givens was always an important facet of the feature, since Scala 2's import pkg._ meant you never knew if you were sucking in implicits, or which implicits.

Edit: I may have missed the point of the previous comment about imports. I think the good illustration for "the second rule" is the example for the fourth rule, where < is available by virtue of Ordering being available. That is in implicit scope, so it makes sense that an implicit value renders an extension available. If lexical and implicit scope have parity, then the second rule follows: it works the same way in lexical scope. For additional motivation, it means import x.{given, *} distinguishes extensions made available by implicit instances and extensions sucked in by *. The latter can be selectively imported by name.

[mr-git]

"How should I structure my extensions?"

This is very interesting topic itself! I am in process of migrating code from Scala 2 to Scala 3 and I have to make hard decision on how to name and structure code!

A big players like Cats and Cats Effect doesn't help much in this case either. For example, in Cats they used to expose all or some implicits in dedicated package, like ...implicits.*, but later suggested to use ...syntax.all.* (though exposing not all of them - some still have to be imported as named ...implicits.<something>) and now they are suggesting to switch back to ...implicits.* form. :)

Some example/template non-trivial project with "canonical" way on how to expose and use/import/provide givens and extensions in libraries and single-module projects would be very good addition to Scala 3!