I’d like to revisit Implicit Member Expressions fo...

# language-proposals

[benleggiero]

I’d like to revisit Implicit Member Expressions for a moment. One reason it was shot down was because Kotlin nearly emulates this with static `import`s. However, something a language with IMEs can do that Kotlin cannot is handle members with identical names. For instance, Kotlin gives several errors for this:

import Foo.*
import Bar.*


enum class Foo {
    a,
    b,
    c
}



enum class Bar {
    a,
    b,
    c
}



fun translate(x: Foo): Bar = when (x) {
    b -> a
    a -> b
    c -> c
}


val fooBar = translate(a)

Error:(21, 30) Kotlin: 'when' expression must be exhaustive, add necessary 'a', 'b', 'c' branches or 'else' branch instead
Error:(22, 5) Kotlin: Unresolved reference: b
Error:(22, 10) Kotlin: Unresolved reference: a
Error:(23, 5) Kotlin: Unresolved reference: a
Error:(23, 10) Kotlin: Unresolved reference: b
Error:(24, 5) Kotlin: Unresolved reference: c
Error:(24, 10) Kotlin: Unresolved reference: c
Error:(29, 24) Kotlin: Unresolved reference: a

And the only way to resolve these is to say Foo.a or Bar.c everwhere a member of either is needed. With proper IME support, .a and .c would do the job every time without ambiguity.

[groostav]

what kinds of use cases would this afford kotlin? Is this a way to help with the annoyance of some API spitting back objects that need to be mapped to your domain objects?

[benleggiero]

This has many uses, @groostav. For me, the main advantage is the unambiguity. I don’t like having to use package/class names or longer-than-necessary object names to disambiguate something that should be unambiguous from its type already.