Skip to content

Opaque types and implicit specificity #9928

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
vincenzobaz opened this issue Oct 1, 2020 · 4 comments
Closed

Opaque types and implicit specificity #9928

vincenzobaz opened this issue Oct 1, 2020 · 4 comments
Assignees

Comments

@vincenzobaz
Copy link
Contributor

Minimized code

trait Magic[F]:
  extension (x: Int) def read: F

object Magic:
  given Magic[String]:
    extension(x: Int) def read: String = 
      println("In string")      
      s"$x"

opaque type Foo = String
object Foo:
  import Magic.{given _}
  def apply(s: String): Foo = s

  given Magic[Foo]:
    extension (x: Int) def read: Foo =
      println("In foo")
      Foo(s"$x")
  
  def test: Unit =
    (3.read: Foo)
  

@main def test = {
  Foo.test
}

Output

In string

Expectation

In foo

Remarks

  • If import Magic.{given _} is removed, the output is as expected. The question is: should this import change the behavior? given Magic[Foo] should be more specific and preferred to given Magic[String]

Snippet

https://scastie.scala-lang.org/vincenzobaz/tGQhSpQ8TQyiOeTNAvSGbA/104

@b-studios
Copy link
Contributor

I would not expect Foo to be more specific than String in the context of the companion object, since there the equality Foo = String holds.

However, I understand that it is confusing that the (preceding) import shadows the local definition.

Ergonomically, this is related to #9880.

@som-snytt
Copy link
Contributor

I was also confused #8092

In fact, I'm still confused.

@b-studios
Copy link
Contributor

Thanks for reminding me of that issue @som-snytt. There is indeed three different behaviors that would be justifiable.

  1. Local definition shadows (what's described here)
  2. Implicits are stacked as currently implemented and described by @odersky in Implicit resolution (incorrectly?) picks import #8092.
  3. Implicits are in the same scope and trigger an ambiguity.

@odersky odersky self-assigned this Oct 5, 2020
@odersky
Copy link
Contributor

odersky commented Oct 6, 2020

6a898ad implements

  1. Implicits are in the same scope and trigger an ambiguity.

#8092 is unaffected since there the import is properly nested wrt the definition.

@odersky odersky closed this as completed in 6a898ad Oct 8, 2020
odersky added a commit that referenced this issue Oct 8, 2020
Fix #9928: Don't treat import contexts as properly nested
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants