BV
К тому же, обсуждается вполне конкретная проблема. Другое имя к ней отношения не имеет
Size: a a a
2021 January 05
BV
Ну может стоит подцепить ещё одну задачу к задаче Overload resolution, поскольку это идейно всё похоже, но везде чуток не совпадает
Я посмотрю, может и правда стоит добавить
AL
Я посмотрю, может и правда стоит добавить
Ну, основная мысль - выглядит, что вы не делаете чего-либо странного и это баг, который надо либо репортить, либо лайкать :)
VP
А в чём баг, как компилятор должен выводить тип ресивера?
с#
А в чём баг, как компилятор должен выводить тип ресивера?
баг есть, где не работает с простой лямбдой, но работает с переменной (иссью, что @Jellymath выше кидал)
с#
но с ресиверами лучше не сделать
AL
А в чём баг, как компилятор должен выводить тип ресивера?
Ну идейно звучит, что компилятору не должно быть проблемой отличить строку от числа в лямбде:
class Foo {
fun bar(stringMaker: () -> String) {
println("Our maker created ${stringMaker()}")
}
}
fun Foo.bar(intMaker: () -> Int) = bar { "Int: ${intMaker()}" }
fun main() {
val foo = Foo()
val parameter = { 2 }
foo.bar(parameter)
//foo.bar { 2 } //doesn't work
foo.bar { "abc" }
}VP
Ну идейно звучит, что компилятору не должно быть проблемой отличить строку от числа в лямбде:
class Foo {
fun bar(stringMaker: () -> String) {
println("Our maker created ${stringMaker()}")
}
}
fun Foo.bar(intMaker: () -> Int) = bar { "Int: ${intMaker()}" }
fun main() {
val foo = Foo()
val parameter = { 2 }
foo.bar(parameter)
//foo.bar { 2 } //doesn't work
foo.bar { "abc" }
}А, ну это вы про возвращаемый тип функции
VP
Там речь вроде шла про лямбду с ресивером, тип которого отличается
AL
Там речь вроде шла про лямбду с ресивером, тип которого отличается
>у меня есть метод у класса и ещё экстеншен с тем же именем и оба принимают лямду.
Да вроде оно. @fogone если не оно, можешь ради интереса свой пример тоже в чат закинуть? :)
Да вроде оно. @fogone если не оно, можешь ради интереса свой пример тоже в чат закинуть? :)
AL
А, сорри, не увидел. Да, я немного другое скинул.
BV
>у меня есть метод у класса и ещё экстеншен с тем же именем и оба принимают лямду.
Да вроде оно. @fogone если не оно, можешь ради интереса свой пример тоже в чат закинуть? :)
Да вроде оно. @fogone если не оно, можешь ради интереса свой пример тоже в чат закинуть? :)
Ща я сделаю синтетический пример
OY
Ну идейно звучит, что компилятору не должно быть проблемой отличить строку от числа в лямбде:
class Foo {
fun bar(stringMaker: () -> String) {
println("Our maker created ${stringMaker()}")
}
}
fun Foo.bar(intMaker: () -> Int) = bar { "Int: ${intMaker()}" }
fun main() {
val foo = Foo()
val parameter = { 2 }
foo.bar(parameter)
//foo.bar { 2 } //doesn't work
foo.bar { "abc" }
}такое можно заставить работать с аннотацией(точное её название не помню), потому что здесь хотя бы понятно как определять, какую из ф-ий брать
а с ресивером это наверно в общем нереально
а с ресивером это наверно в общем нереально
BV
такое можно заставить работать с аннотацией(точное её название не помню), потому что здесь хотя бы понятно как определять, какую из ф-ий брать
а с ресивером это наверно в общем нереально
а с ресивером это наверно в общем нереально
Компилятор отлично с этим справляется, просто не в случае когда я передаю напрямую лямбду в функцию
BV
а, это он вообще не то вызвал, ща сделаю полный пример
OY
Компилятор отлично с этим справляется, просто не в случае когда я передаю напрямую лямбду в функцию
так я именно про лямбду и говорю, а не когда уже созданную просто как параметр передают
если отличается ресивер - то его же никак не определить кроме как указав его через
если отличается ресивер - то его же никак не определить кроме как указав его через
fun T.() {}BV
так я именно про лямбду и говорю, а не когда уже созданную просто как параметр передают
если отличается ресивер - то его же никак не определить кроме как указав его через
если отличается ресивер - то его же никак не определить кроме как указав его через
fun T.() {}так я делаю
as T.()->Unit и это не помогаетVP
так я делаю
as T.()->Unit и это не помогаетСомневаюсь, что кастовать один функциональный тип к другому - это хорошая затея. Но странно, что это не помогает.