Даже если на лету генерировать изменённый инпут стрим с помощью трансформации, я не вижу никаких полезных экстеншнов на тему.

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

Да без задачи все равно ничего не понятно

Превратить в инпутстрим можно только ByteArray из похожих структур данных.

На лету трансформировать input stream - это весьма экстравагантное дело, которое лучше отдельным классом делать.

Ну какие-то кейсы вроде XOR-шифрования легко одним условным transform делать. Даже более сложные вещи, где надо вычитывать больше байта за раз, я себе могу представить. Но, вероятно, это достаточно редкая задача, потому готового в стдлибе ничего и нет.

Можно попробовать попросить добавить: kotl.in/issue (но придётся хорошо аргументировать)

Ну это понятно что в него нельзя, но можно же FilterInputStream или что то в этом роде юзат?
Задача такая достать html из assets и поменять в ней одно значение и загрузит всю эту красоту в WebView

1) Достаю html в InputStream
2) Делаю стрингу
3) Делаю реплейс в стринге
4) Обратно возврашаю в InputStream для загрузки в WebView

Выглядит как будто это будет медленно работат

Всё так. выглядит жирновато.

Собсна, FilterInputStream вроде никто не отбирал, пользуйтесь на здоровье.

Ну вот и подумал может в котлине какой нит екстеншн добавили для того чтобы не гемороится) Но походу нет)

Я не удивлюсь, если чёт похожее можно будет делать в kotlinx.io, но для джавовых стримов нет таких экстеншнов, увы.

А зачем обратно в inputstream? Webview же принимает string.

ну мне нужно WebResourceResponse о его можно только по моему сылкой на ури и инпут стримом делать)

Ну может оно и есть, просто нам не знакомо еще)

Народ, а может кто-то сказать -  в каких ситуациях стоит использовать inline функции?

2 основных варианта использования:
1. Если функция высших порядков (принимает на вход другую функцию), чтобы избежать накладных расходов по созданию объекта для передаваемой функции и динамическому вызову кода.
2. В комбинации с reified типами - параметрами, чтобы получить информацию о типе - параметре во время исполнения (класс и прочее). По сути, reified позволяет избежать type erasure для типов - параметров.

Вдобавок к написанному выше про функции высших порядков: инлайнинг лямбд ещё не только оптимизация, но и предоставление дополнительных возможностей:
* Возможность писать всякие return и прочие вещи, актуальные для места вызова
* Возможность писать условно всё, что можно писать в месте вызова. Условно если вы делаете userIds.map { loadUser(it) } и loadUser это suspend функция, то внутри лямбды вы можете эту функцию вызывать из-за того, что map - это инлайн функция (предполагая, что всё действие происходит в свою очередь в suspend функции)

Это норма, что приложение уже месяц на модерации в Google Play?

напиши им в лайв чат, у них крайне странный саппорт