Гредловая модель всегда опережала модель проектов идеи, так что сама ситуация, когда в гредле работает, а в идее нет -- норма.
Касательно нейтива и сорс-сетов команда работает над hierarchical multiplatform projects (HMPP), но я не знаю о текущем состоянии дел.

Впрочем, я и жалобы на красную идею реже вижу.

Можете в @kotlinmppchats спросить, там большая концентрация людей с релевантным опытом :)

да я и в слаке спросил, и на ютреке :)

Workaround https://github.com/badoo/Reaktive/blob/453fa4d733d0e470473719d39d8a41a0c192f5be/reaktive/build.gradle#L9

да, я о чём-то таком подумал, но городить не стал :D
спасибо

Как я понял, там довольно ограниченный набор инструкций для возврата значений, плюс есть какие-то дополнительные валидации байткода, мешающие реализовать множественный возврат.

Не помню, где я хороший разбор видел (но он точно был не о котлине), но начать можно отсюда
https://discuss.kotlinlang.org/t/multiple-return-types-from-function/664/9

в актуальном байт-коде? Ну так да, именно поэтому у инлайн-класса только один val, и именно это хотят исправить в Вальхалле

Ну так тут выше по треду и обсуждают инлайн-классы на несколько полей

Тред не читай
@
С вопросами врывайся

вот, я же и спрашиваю, о чём тред :)

Хех)

Есть в чяте ещё итерасты вроде меня?

Что-то я ни идеологически, ни технически адекватно не понимаю твоей хотелки.

Идеологически:
Ты просишь выставить наружу кусок стандартной либы, потому что тебе не нравится как сделан этот же кусок стандартной либы. Не означает ли, что надо как минимум нормально собрать мысли и показать, что не так в стандартной либе (нет, вот эти две строчки про сиквенсы - это не "показать что не так")

Технически:
Из описания совсем непонятно что вообще надо выставить наружу? Классы? Так функции считай их же и инстанциируют. Реализацию итератора? Либо также будет завязана на сиквенс, либо не очень реально, ибо структурной типизации нету (нельзя попросить на вход абстрактное что-то у чего есть итератор). Вытащить функцию Iterator -> Iterator? Вроде будут аллокации лишние и у тебя, и в стандартной либе.

Итераторы никак не завязаны на сиквенсы. Там, где написано val iterator = sequence.iterator(), можно сделать параметр конструктора.

Т.е. выставить преобразование Iterator -> Iterator, окей. Но чем тебе поможет такой объект, если ты только что жаловался на аллокации?

Тем, что я смогу создавать его, не создавая бесполезный сиквенс

1. Сильное утверждение, что сиквенсы бесполезны.
2. Стоит ли выставлять в публичный доступ, то что в среднем случае никому не надо (по крайней мере кроме как от тебя я не слышал мысли, что работать напрямую с итераторами это норм тема)
3. Стоит ли просить в стандартной либе что-то, что идёт в противовес остальной либе по использованию? Не проще ли скопипастить себе всё полезное и не использовать стандартную либу?

Если бы я мог не использовать стдлибу, вопроса бы в принципе не существовало.

«Сильное утверждение» это какая-то демагогия.

>  they are just useless classes loaded into memory
Далеко пойдёшь с такими issue 😄

Да чёт количество пассивной агрессии в моей речи неумолимо растёт.

Получается вместо цепочки сиквенсов ты хочешь делать что-то вроде
DistinctIterator(FilteringIterator(myIterator, ...), ...)?