Import Implied #5868
Import Implied #5868
Conversation
odersky
force-pushed
the
add-import-implied
branch
from
423db5f to
39efcfa
Compare
|
I am counting on the bootstrap to test this in anger, both for functionality and for usability. Adding it now, since it is always better to start more restrictive instead of tightening the rules later. |
We need that for pretty printing, and generally, to distinguish the two styles for implicits.
Align with usage elsewhere where a flag name normally applies to both terms and types, and is qualified with Term or Type if we want only one half.
I get it that `toMessage` will give a more precise error message. But that's no reason to hide the message obtained from `getMessage` completely.
Interpretation of what `implied` means is still missing.
Implied imports can only import implied definitions. Regular imports can only import non-implied definitions.
The change of Implicit to be a common flag now caused some breakage, which this commit fixes.
Add implied import entry to sidebar
odersky
force-pushed
the
add-import-implied
branch
from
12ded36 to
cd1c914
Compare
There was a problem hiding this comment.
This seems to be a first-step of a paradigm shift from definition-site implicits to use-site implicits. I like this transition.
However, it seems there is a little issue with programmer's intuitive understanding of lexical scoping and import A._. The discussion is embedded inline.
| object B { | ||
| import A._ | ||
| foo // error: no implicit argument was found | ||
| foo given tc // error: not found: tc |
There was a problem hiding this comment.
Forbidding explicit usage of tc here is a little counter-intuitive to lexical scoping, given the literal reading of import A._.
What about the following:
import A._to import all members for explicit usageimplied A._to enable implied instances defined inAfor implicit resolutionimplied A.cmakeA.cavailable for implicit resolution, no matter A.c is implicit or not.
The last one is up to debate, the idea is to encourage use-site implicits over definition-site implicits.
There was a problem hiding this comment.
Would it be possible to use this feature to make any member a candidate for implicit resolution in scope, i.e. import implied A.foo?
|
@liufengyun What you propose is definitely worth considering. There's a complication however, in that the "implicitness" of a definition now depends not only on its definition, but also on the way it is imported. This is likely to have profound effects on spec and implementation. The current PR avoids this problem, and results in the narrowest possible import semantics. So I propose to get this in now since we can always generalize later. |
| @@ -18,7 +18,7 @@ import config.Printers.cyclicErrors | |||
| class TypeError(msg: String) extends Exception(msg) { | |||
| def this() = this("") | |||
| def toMessage(implicit ctx: Context): Message = super.getMessage | |||
| override def getMessage: String = throw new Exception("Use toMessage instead for TypeError") | |||
| override def getMessage: String = super.getMessage | |||
There was a problem hiding this comment.
The call super.getMessage will get empty string, which may hide useful error messages.
| @@ -324,7 +325,8 @@ object TastyFormat { | |||
| final val OPAQUE = 35 | |||
| final val EXTENSION = 36 | |||
| final val GIVEN = 37 | |||
| final val PARAMsetter = 38 | |||
| final val IMPLIED = 38 | |||
| final val PARAMsetter = 39 | |||
There was a problem hiding this comment.
Advance tasty version, as the format changes?
Introduce a new form
import impliedto import implied instances. Regular imports don't touch them anymore. See: 16cb974 for the docs.