Телеграмм чат группы pofftop страница 10783

19:41пожаловаться #1

(

Всегда казалось, что возвращаемый тип не включается в сигнатуру

В JVM включается, в Java нет

19:44пожаловаться #2

Konstantin Dovnar in Programming Offtop

Alexander Nozik

В JVM включается, в Java нет

Как это так? Я могу написать валидный код на Java, который будет не валиден на jvm?

19:46пожаловаться #3

Как это так? Я могу написать валидный код на Java, который будет не валиден на jvm?

Наоборот. Можно написать невалидный код на java, который будет при этом теоретически возможен в байт-коде

19:47пожаловаться #4

Как это так? Я могу написать валидный код на Java, который будет не валиден на jvm?

Наоборот.

19:47пожаловаться #5

JVM позволяет больше, чем Java.

19:47пожаловаться #6

Andrew Mikhaylov

JVM позволяет больше, чем Java.

Да, в чем-то больше, в чем-то меньше. К примеру дженериков в Jvm нет. Они только на языковом уровне

19:48пожаловаться #7

Alexander Nozik

Да, в чем-то больше, в чем-то меньше. К примеру дженериков в Jvm нет. Они только на языковом уровне

Аргумент

19:48пожаловаться #8

Konstantin Dovnar in Programming Offtop

Хм.
Погодите.
В Java возвращаемый тип не включается.

Т.е.

int foo() { return 1; }
double foo() { return 1.0; }

валидный код. Но на JVM оно свалится.

19:50пожаловаться #9

Хм.
Погодите.
В Java возвращаемый тип не включается.

Т.е.

int foo() { return 1; }
double foo() { return 1.0; }

валидный код. Но на JVM оно свалится.

Наоборот, оно нескомпилируется. Но функции с такой сингатурой могут существовать в байткоде

19:51пожаловаться #10

Хм.
Погодите.
В Java возвращаемый тип не включается.

Т.е.

int foo() { return 1; }
double foo() { return 1.0; }

валидный код. Но на JVM оно свалится.

Возвращаемый тип не включается в сигнатуру, по которой делаются перегрузки -> несколько методов с разницей только в возвращаемом типе имеют идентичные сигнатуры для правил перегрузки -> не скомпилируется

19:52пожаловаться #11

При этом в котлин скомпилируется, если ошибка и будет, то в месте использования, если компилятор не может тип вывести

19:54пожаловаться #12

Alexander Nozik

Ух ты, а я и не пробовал. А как оно на границе интеропа себя чувствует?

19:56пожаловаться #13

Andrew Mikhaylov

Ух ты, а я и не пробовал. А как оно на границе интеропа себя чувствует?

Без понятия, у меня 100% котлин уже с год как. Я пробовал, работает. Но да, в месте использования надо явно как-то тип указывать

19:57пожаловаться #14

Надеюсь, не забуду попробовать, как у машины буду :)

19:57пожаловаться #15

Andrew Mikhaylov

Надеюсь, не забуду попробовать, как у машины буду :)

Хотя на простом примере выдает conflicting overloads... Странно

19:59пожаловаться #16

Konstantin Dovnar in Programming Offtop

А, всё, понял.
Так ещё куда не шло, ибо на моменте компиляции грохнет.

20:01пожаловаться #17

The types of the parameter list, together with the return type, is known as a function's signature, but the return type cannot be used to disambiguate overloaded functions.

20:05пожаловаться #18

Таки я не прав, там по сигнатуре можно отличать функции, но перегружать нельзя.

20:05пожаловаться #19

Overloaded function with lambda parameter of different return types

Во, нашел: https://discuss.kotlinlang.org/t/overloaded-function-with-lambda-parameter-of-different-return-types/6053/2?u=darksnake

Kotlin Discussions

Is there any solution for having several same-named functions for different lambda return types, like the following: fun execute(code: () -> Int) {} // declaration clash warning fun execute(code: () -> String) {} // declaration clash warning Even annotating those functions with @JvmName("executeInt") and @JvmName("executeString") respectively doesn’t help because the call execute{ "ok" } is highlighted with “Overload resolution ambiguity” warning. And if the answer to the first question is “...