Context parameters #366
Context parameters #366
Conversation
| logWithTime("hello") // ambiguity error | ||
|
|
||
| context(console: ConsoleLogger, file: FileLogger) fun example1b() = | ||
| logWithTime("hello") // ambiguity error |
There was a problem hiding this comment.
Wouldn't logWithTime be unresolved here instead of an ambiguity error? From my understanding, the type of a named context parameter isn't part of the scope inside the function. Or am I wrong here?
There was a problem hiding this comment.
No, in every case logWithTime is resolved to the top-level function. The difference is whether there's ambiguity or not in the "context resolution" phase.
Co-authored-by: Luca Kellermann <[email protected]>
Co-authored-by: Gleb Minaev <[email protected]>
|
|
||
| **§26** *(applicability, `DslMarker`)*: During context resolution, if at a certain scope there is a potential contextual value in scope (either coming from a context parameter or from an implicit receiver) marked with an annotation `@X` which is itself annotated with [`@DslMarker`](https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/-dsl-marker/) then: | ||
|
|
||
| - It is an _error_ for two such values to be available in the same scope. |
There was a problem hiding this comment.
Even if only one of them is applicable?
|
|
||
| - It is an _error_ for two such values to be available in the same scope. | ||
| - If context resolution chooses a contextual value with the same annotation, but in an outer scope, it is a compilation _error_. | ||
| - If a call binds to a receiver with the same annotation, it is a compilation _error_. |
There was a problem hiding this comment.
TBH, I don't understand what this part means. May you please give some example?
|
|
||
| **§2.1** *(`context` function)*: The `context` function adds a new value to the context, in an anonymous manner. | ||
|
|
||
| * The implementation may be built into the compiler, instead of having a plethora of functions defined in the standard library. |
There was a problem hiding this comment.
This likely would complicate providing documentation for them.
There was a problem hiding this comment.
We might need to be a bit more creative here. Maybe the regular Dokka-style docs are not good in this case; I would imagine this being part of the language documentation, given how central they are going to be to the context parameters feature itself.
| ``` | ||
|
|
||
| We strongly advise _against_ creating "copies" of an API but with an added context parameter. | ||
| Overload resolution is tricky, and the developer may end up calling the unintended version. |
There was a problem hiding this comment.
The example doesn't illustrate what is dangerous in this case.
Only comment here about the text itself. The discussion about the feature is done in this issue.
This is an updated proposal for KEEP-259, formerly known as context receivers. The new design addresses the issues raised by the users of the prototype and across the community.