This thought was inspired by import-export keywords duality discussion. I see there that the import keyword was considered as two different words with two different meanings:
- using
importfor bringing names into the local namespace to use those names locally; - using
importfor bringing names into the namespace of those which import myself.
The proposal was to have different words, one for each meaning. Before invention of another word we have something like two different (key)words that are homonyms.
What I want to take your attention to is that we have the similar situation with the implicit keyword. We have kind of two different implicits:
-
External or non-scope-local implicit. Those that we have when we are declaring a method with an implicit parameter.
implicitkeyword denotes a thing that is actually implicit for our caller (if he wants, of course). - Internal or scope-local implicit. This is a thing that we a willing to be implicit in our scope and does not force anyone else to treat it as implicit thing. It can be a local implicit variable or method declaration. Also, some proposals like this or that attempt to give another way of declaring internal implicits.
In fact, the border between them is not so clear. At first, implicit parameter declaration (i.e., external implicit) actually imposes also an internal one, i.e. it also brings an implicit value into the local scope. Also, when we are declaring public fields or methods that have implicit keyword, we are doing this not only for our local scope but for those who we are exporting our definition to.
Well, Iām actually not proposing to have different keywords for these two meanings of the implicit keyword (yet 
), but I think we need to think about consequences of such homonymy to find a moment where those meanings begin to disturb or contradict each other. Maybe, we should preserve kind of a list of homonyms in the language (like some attempts to list all the meanings of the underscore exists).