I'm using them in order to avoid signature clash (...

# random

[elect]

I'm using them in order to avoid signature clash (different return type)
would it be possible to do the same as Swift, like here https://stackoverflow.com/a/28079432/1047713 ?

[gildor]

JVM includes return type to method signature, but because Java doesn’t, It wouldn’t be possible to support in Kotlin because of interop

[elect]

oh, this is weird.. why has this decision been taken?

[gildor]

What kind decision?

[gildor]

to have interop with Java? %)

[elect]

Java not supporting return type to signature, althought JVM includes it

[gildor]

because Language != VM 🤷

[gildor]

Language may limit some features of VM if language designers want

[elect]

anyway, I dont really see interop like an abstacle here

[elect]

Kotlin may extend some java limitations

[elect]

(like it indeed does with reified btw..)

[gildor]

than it would make impossible to call such functions

[gildor]

reified is not extending, it’s just syntactic sugar for Class argument

[elect]

or for example methods using inline classes

[gildor]

also this cause a lot of problems with overloading, like which version of the method compiler should select

[gildor]

this is easy on JVM side, because you always specify return type on method call

[gildor]

but in the language it may cause a lot of problems, because you cannot specify return value

[elect]

we may do as Swift, https://stackoverflow.com/questions/13314316/why-is-the-return-type-of-method-not-included-in-the-method-signature/28079432#28079432

[gildor]

yes, I do not say that it’s impossible

[gildor]

I just say that it cause many problems with inference and resolution

[gildor]

and all infamous example of recursive type inference in Swift also doesn’t make think good about this decision

[tapchicoma]

infamous example of recursive type inference in Swift

Just curious - can you point me to some example of it?

[gildor]

Like this:

[gildor]

https://stackoverflow.com/questions/34911516/compiling-swift-source-files-hangs-on-large-array-reduce-combine-expressions

[gildor]

There is a plenty of similar examples

[gildor]

not sure which of them are exist on each versions, but just an example

[gildor]

also there are recommendations like “use explicit types to make compilation faster”

[gildor]

For example
https://www.hackingwithswift.com/articles/11/how-to-make-swift-compile-faster

[tapchicoma]

interesting 🤔

[gildor]

Right now, the canonical example of problematic code looks something like this:

let sum = [1, 2, 3].map { String($0) }.flatMap { Int($0) }.reduce(0, +)

That converts an array of integers into an array of strings, then back to an array of integers, and adds them up.

It’s not the kind of code you’d write in anything serious, of course, but it does illustrate a problem: what might seem like fairly trivial work to us actually takes over 11 seconds to compile on a top of the range MacBook Pro.

[gildor]

I of course don’t want to say that all those problems caused by including return type to signature, I just want to say that resolution and inference is hard, and return type in signature make it even harder

[gildor]

recursive type inference in Swift

Probably “recursive” is bad word, more precisly in those cases we see combinatorial explosion problem with type inference