Skip to content
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

Support contextual dependent extensions #9530

Closed
nicolasstucki opened this issue Aug 11, 2020 · 2 comments · Fixed by #10940
Closed

Support contextual dependent extensions #9530

nicolasstucki opened this issue Aug 11, 2020 · 2 comments · Fixed by #10940

Comments

@nicolasstucki
Copy link
Contributor

Minimized example

We should support

trait Scope:
  type Expr

extension (using s: Scope)(expr: s.Expr)
  def show = "expr"

def f(using s: Scope)(s.Expr) = s.show

or the less performant

trait Scope:
  type Expr

given (using s: Scope) as AnyRef:
  extension (expr: s.Expr)
    def show = "expr"

def f(using s: Scope)(expr: s.Expr) = expr.show

Expectation

One of those should be supported to be able to encode

implicit class Ops(using s: Scope)(e: s.Expr):
  def show = "expr"

which does work and has several use cases.

@odersky
Copy link
Contributor

odersky commented Aug 14, 2020

Here's the second example if we write-out the extension method and given:

trait Scope:
  type Expr

object test:
  given G(using s: Scope) as AnyRef:
    extension (expr: s.Expr)
      def show = "expr"

  def f(using s: Scope)(expr: s.Expr) =
    G(using s).extension_show(expr)

This will give the following error:

-- [E007] Type Mismatch Error: ../new/test.scala:10:30 -------------------------
10 |    G(using s).extension_show(expr)
   |                              ^^^^
   |                         Found:    (expr : s.Expr)
   |                         Required: ?1.s².Expr
   |
   |                         where:    ?1 is an unknown value of type test.G
   |                                   s  is a value in method f
   |                                   s² is a value in class G
result of ../new/test.scala after typer:

Why becomes clear when we look at the expansion after typer:

result of ../new/test.scala after typer:
package <empty> {
  trait Scope() extends Object {
    type Expr >: Nothing <: Any
  }
  final lazy module val test: test$ = new test$()
  final module class test$() extends Object(), _root_.scala.Serializable { 
    this: test.type =>
    class G(using s: Scope) extends AnyRef() {
      protected given val s: Scope
      extension (expr: G.this.s.Expr) def show: String = "expr"
    }
    final given def G(using s: Scope): test.G = new test.G()(using s)
    def f(using s: Scope)(expr: s.Expr): String = 
      test.G(using s).extension_show(expr)
  }
}

The given def only knows that it returns a G but loses the information about what the scope parameter was.

@nicolasstucki
Copy link
Contributor Author

@odersky odersky self-assigned this Dec 27, 2020
odersky added a commit to dotty-staging/dotty that referenced this issue Dec 28, 2020
odersky added a commit to dotty-staging/dotty that referenced this issue Dec 31, 2020
odersky added a commit to dotty-staging/dotty that referenced this issue Jan 1, 2021
odersky added a commit to dotty-staging/dotty that referenced this issue Jan 4, 2021
odersky added a commit to dotty-staging/dotty that referenced this issue Jan 5, 2021
nicolasstucki pushed a commit to dotty-staging/dotty that referenced this issue Jan 5, 2021
nicolasstucki pushed a commit to dotty-staging/dotty that referenced this issue Jan 5, 2021
nicolasstucki pushed a commit to dotty-staging/dotty that referenced this issue Jan 5, 2021
nicolasstucki pushed a commit to dotty-staging/dotty that referenced this issue Jan 6, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants