`jvmModifiers` doesn't return the Builder

[ShaishavGandhi]

The method jvmModifiers in FunSpec breaks the chaining by not returning the Builder. There is a similar method in ParameterSpec which does return the Builder.

This will be a breaking change so it will have to wait till 2.x.

[JakeWharton]

It doesn't need to wait.

@JvmName("jvmModifiers")
@Deprecated(level = HIDDEN)
fun jvmModifersOld(..) { .. }

@JvmName("jvmModifiersNew")
fun jvmModifers(..): Builder { .. }

[Egorand]

Wouldn't it break implicit returns in Kotlin though? Also, introducing jvmModifiersNew() for Java call-sites to remove it in 2.0 kinda sucks...

[JakeWharton]

Wouldn't it break implicit returns in Kotlin though?

Yes it is source incompatible but literally (and not hyperbolically) no one is relying on this. It would have to be the last function call on the builder when used as an expression.

Also, introducing jvmModifiersNew() for Java call-sites to remove it in 2.0 kinda sucks...

I mean you can name it whatever you want, but I'm not sure how much I care about the ergonomics of Java callers here. Android suffixed their methods with "Flags" when they made this change.

You can also use bytecode manipulation to break neither binary nor source compatibility: https://github.com/JakeWharton/OverloadReturn

[Egorand]

Yeah, agree. Fine with both fixing it now the way you suggest, or leaving it hanging until 2.0. The workaround is straightforward (.apply { jvmModifiers(...) }, so the issue probably doesn't really inconvenience anybody.

[anatawa12]

Sorry, This comment may not be good for here.
I think we/you can make an future-request for kotlin.
if we use @Deprecated("", level = DeprecationLevel.HIDDEN), we can't see the method/property from any new source code and can call from old code.(method signature in JVM includes return type.) So I think Kotlin should allows this source. I think this future is good for fix this without breaking changes.

@Deprecated("", level = DeprecationLevel.HIDDEN)
fun test(){}
fun test(): Any = Any()

[Egorand]

I don't think that DeprecationLevel.HIDDEN is broken, it's designed to break source compatibility without breaking binary, which serves a common case - you want to break your library's direct consumers and have them change their code, but you don't want to break consumers who use your library transitively as a dependency of another library they use.

[anatawa12]

you seem to want to make functions which same-name, same-parameter and different-result-type to fix this. But current Kotlin doesn't allow(see https://pl.kotl.in/wITeF-6gG). I think we can make a future request for Kotlin. This is a suggestion about what we can do.

[Egorand]

This is not something that Java allows either, and I'm pretty sure it's not allowed by the JVM spec (correct me if I'm wrong).

[JakeWharton]

It's allowed in bytecode, not source code.

[anatawa12]

In the new java source code, the function with DeprecationLevel.HIDDEN is hidden in java too and can invoke new function.
In current Kotlin, not allowed but I think we can make a request to allow.