Kotlin: define constructors that throw for async functions

[bendk]

These constructors always just throw an exception, since Kotlin doesn't supprot async constructors. This is less confusing for users than just skipping the codegen (#2804).

[paxbun]

How about adding @Deprecated or opt-in annotations to such constructors? With this, we can notify users at compile time that async constructors are not supported in Kotlin as well.

[bendk]

In #2804 we discussed making the codegen fail at build time, however I went with this approach for a couple reasons:

• It matches how we handle things in Python
• I could see a use-case for a library that defined an async constructor knowing that it only worked on some bindings and providing an alternative method for other bindings. This is how fixtures/futures works actually.

I'm not totally sure this is the right way though, a build-time failure would be nicer in many cases compared to generating code that's just going to throw when you use it. However, that second bullet feels important to me. Maybe we could extend the language-specific config code that allows function/method renaming to also allow skipping codegen for functions/methods. That would give those users a decent path forward: they just need to add the constructor to that skip configuration.

[paxbun]

I'm not sure I understood the comment correctly, but @Deprecated will just warn the users, not cause compilation errors. If the users know this async constructor behavior, they can explicitly suppress the deprecation using the @Suppress annotation.

[bendk]

My comment wasn't a response to yours, we just happened to post at the same time. It was more me thinking out-loud on other ways to handle this.

Adding @Deprecated would be okay with me. I think that might be an improvement over the current code. However, I'm still wondering if a build error at codegen time would be the best behavior.

[paxbun]

I think this will be confusing to many users, but we can simulate async constructors in Kotlin by adding suspend operator fun invoke(...) to the companion object. I've never seen an actual production-level code that does this, though.

class Foo private constructor(public val v: String) {
  override fun toString() = "Foo($v)"
  companion object {
    suspend operator fun invoke(v: Int): Foo {
      return Foo(v.toString())
    }
  }
}

fun main() = runBlocking {
  println(Foo(15)) // invoking Foo.Companion.invoke(15)
}

[paxbun]

https://github.com/search?q=%22suspend+operator+fun+invoke%22+%22companion+object%22+language%3AKotlin&type=code

There seem to be several libraries that actually do this. Maybe it would be okay to implement async constructors like this.

[pronebird]

If I understand it right this will result in runtime error. I am not particularly fond of this solution since CI checks will pass and give a false sense of safety.

Rust supports conditional compilation so it's possible to handle differences for android/ios by providing alternative constructors. As such build error isn't a problem but would help catch issues early on during CI pass

[bendk]

If I understand it right this will result in runtime error. I am not particularly fond of this solution since CI checks will pass and give a false sense of safety.

I agree with this and made #2822 as a way to move us towards build-time errors.

[mhammond]

IIUC, you don't want to do this now, but would rather throw at bindgen time?

[mhammond]

this comment is now wrong?