Extension functions on classes that have class context receivers (e.g.

context(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 intuitively

IMO making Foo carry along Hello and World nearly invisibly is not good. perhaps something like

class Foo
context(val Hello, val World) constructor()

Agreed, but there is an argument for Foo having access to those contexts everywhere in its body, and in that case, I'd argue that carrying that behavior over to extension funs and (maybe) context funs will be more consistent than just hiding those inner contexts