So, I am running into a problem with extension function because of Jvm name clashes. In my particular case I need to offer two similar functions operation on either a non-nullable type X and on a nullable type X.

infix fun <T> String.blah(processor: (String)->T): T

infix fun <T> String?.blah(processor: (String)->T): T?

Normally, such problems can be fixed by adding a specific

@JvmName

annotation to at least one of the two methods - but in this case you get an error, stating "'@JvmName' annotation is not applicable to this declaration". This is quite a downer.. why is that and how can I make this compile? I thought an extension function is nothing special at all, in my case a function with two arguments... Any chance I might get this working? Thanks!

Are you inside an interface? Also, you could add a

unit: Unit = Unit

to the nullable function (so that even though the non-null is now higher priority, the nullable will still be called for nullable arguments)

Yes, I am in an interface with default implementation. I just left out the implementation, you can put = TODO() there to see the error. But the problem is also there outside of interfaces / classes. I do not really get what you mean by add

unit: Unit = Unit

... can you put that in context, please. Does that fix my problem?

This works:

interface Test {
    infix fun <T> String.blah(processor: (String)-> T): T = processor(this)

    @Suppress("INAPPLICABLE_INFIX_MODIFIER")
    infix fun <T> String?.blah(processor: (String)-> T, unit: Unit = Unit): T? = this?.let(processor)
}
class TestImpl: Test
fun main(){
    val nullable: String? = null
	val test = with(TestImpl()) { "hello" blah { it } }
	val test2 = with(TestImpl()) { nullable blah { it } }
    print(test)
    print(test2)
}

the suppress is needed since the unit parameter makes the function have 3 params. I don't think there's a way around that, but thankfully the suppress is sufficient to not cause any issues

That's a cool idea. I tried adding a parameter, but didn't know I could suppress the error that this is not an infix fun anymore. In the meantime, I worked around my problem with a

@JvmInline

class as a wrapper around my nullable Receiver - technically this does exactly what I wanted, when you look at the bytecode there's a function with a name

blah_something

for my nullable Receiver. What I still would like to understand from the makers of the Kotlin compiler is, why I cannot just use

@JvmName

on my second infix fun...

It's because it's an interface, and there's no way currently to force interface inheritors to use the correct

JvmName

annotation.

Cool, makes sense. Thanks!

This also works:

interface Test {
    infix fun <T> String.blah(processor: (String)-> T): T = processor(this)

    @Suppress("INAPPLICABLE_JVM_NAME")
    @JvmName("blahNullable")
    infix fun <T> String?.blah(processor: (String)-> T): T? = this?.let(processor)
}

What I really sometimes find hard to understand is that you can suppress an error and still "hope" for it to work as expected. Seems weird. Like as if I opt out of a guarantee. And: some errors are errors because it simply cannot work and other seem to be nothing more than a good advice, but you can ignore them. Which one is which is not really clear...

Some errors exist because the language isn't "intended" to do certain things. They're there to enforce the spec of the language, and hence to allow future changes without breaking any supported use case. Other errors are genuinely compiler-breaking. When you suppress an error, you basically give the compiler a "Shut up, I know what I'm doing" signal, and if it breaks later on, then it's your fault. Hence, IDE will never recommend a suppression for an error. The way I find out these suppression magical strings is by turning on internal mode in intellij, which shows the error name next to its description

Thanks again @Youssef Shoaib [MOD], all of your answers were more than helpful! One follow up regarding Context Receivers, which I really cannot wait to get released for good! My DSL where my blah infix function is at home uses the Kotlin Script compiler on user Kotlin snippets. I wouldn't actually know how to enable experimental features like Context Receivers on this Script Engine at all... any hints?

I'm not sure if the scripting compiler has support just yet for that. I'd suggest you instead use Kscript, which uses the jvm compiler under the hood, and allows you to configure compiler options