Thread
#language-evolution
    y

    Youssef Shoaib [MOD]

    5 months ago
    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
    e

    ephemient

    5 months ago
    IMO making Foo carry along Hello and World nearly invisibly is not good. perhaps something like
    class Foo
    context(val Hello, val World) constructor()
    y

    Youssef Shoaib [MOD]

    5 months ago
    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