Youssef Shoaib [MOD]
04/14/2022, 4:39 PMcontext(Hello, World) class Foo { ... }
) should be able to access those class's receivers.
Additionally, maybe the same behaviour can be applied to a context receiver that is a context class. Lemme explain with an example:
class Hello { fun hello(name: string) = TODO()
class World { val value = 42 )
context(Hello, World) class Foo
fun Foo.fooExtender() {
// I should be able to call this with no issues
hello(value)
}
context(Foo) fun doSomethingInFooContext() {
// I should be able to call this with no issues
hello(value)
}
If the behavior for the doSomethingInFooContext
is too surprising, maybe we can have a special keyword for it (i.e. propagate
or something), or, we can only allow Hello and World to propagate through if Foo is available as a normal receiver and not a context one (IMO this is surprising and unintuitive).
Something to think about though is that if this is implemented, it'll be best to treat those class contexts as a heirarchy level above the other contexts (e.g. resolution order should be Foo's contexts are "weaker" than foo itself) and I recall that such heirarichal behaviour was considered unintuitive before, but it seems like it could be a necessary evil if we want class contexts to work intuitivelyephemient
04/14/2022, 4:45 PMclass Foo
context(val Hello, val World) constructor()
Youssef Shoaib [MOD]
04/14/2022, 4:51 PM