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

Accessor methods for implicit values is not created. #4779

Closed
scabug opened this issue Jul 7, 2011 · 2 comments
Closed

Accessor methods for implicit values is not created. #4779

scabug opened this issue Jul 7, 2011 · 2 comments
Assignees

Comments

@scabug
Copy link

scabug commented Jul 7, 2011

The following code are compiled without error.
However, if the line "implicitlyBar" is commented out, I get a error "could not find implicit value for parameter e: Bar".

class Foo {
  def foo {
    implicitly[Bar](Bar.bar)
    implicitly[Bar]
  }
}

class Bar

object Bar {
  implicit val bar = new Bar
}

Inspecting an output of -Xprint:typer, the accessor method for implicit value Bar.bar is not generated.

  ...
  final object Bar extends java.lang.Object with ScalaObject {
    def this(): object Bar = {
      Bar.super.this();
      ()
    };
    private[this] val bar: Bar = new Bar()
  }
  ...

When explicitly declare the type of Bar.bar, it is compiled without error.

class Foo {
  def foo {
    implicitly[Bar]
  }
}

class Bar

object Bar {
  implicit val bar: Bar = new Bar
}

However, the following code cannot be compiled.

class Foo {
  def foo {
    implicitly[Bar]
  }
}

class Bar

object Bar {
  val b: Bar = new Bar
  implicit val bar = b
}

Moreover, when reordering class definition, the code is compiled.

class Bar

object Bar {
  implicit val bar: Bar = new Bar
}

class Foo {
  def foo {
    implicitly[Bar]
  }
}

Is this intented behavior?

@scabug
Copy link
Author

scabug commented Jul 7, 2011

Imported From: https://issues.scala-lang.org/browse/SI-4779?orig=1
Reporter: takuo
Affected Versions: 2.9.0
Duplicates #5618

@scabug
Copy link
Author

scabug commented Jul 7, 2011

@paulp said:
This is all the expected behavior, but I can't find it explained in the spec. We're overdue to get something specified about the significant influence which declaration of return type has on implicit eligibility.

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

2 participants