When a function takes a `Closeable` as a parameter is there

Question

When a function takes a `Closeable` as a parameter is there a nice way to indicate whether the function actually closes the `Closeable` or if it s the caller responsibility Ideally looking at the signature only

louiscad · Answer

Name it `useXxx` if it closes it

mbonnin · Answer

~ ~ gotcha

mbonnin · Answer

Makes sense thumbsup

louiscad · Answer

One example is `useLines`

mbonnin · Answer

So I guess `Json decodeFromStream InputStream ` doesn t close the inputStream

louiscad · Answer

Good question

louiscad · Answer

I d think it does

louiscad · Answer

Looks like a terminal operation to me

mbonnin · Answer

It does look like a terminal operation

mbonnin · Answer

But thinking a bit more about it there are use cases where you have Json in the middle of an otherwise text document

louiscad · Answer

InputStream is not just a Closeable

mbonnin · Answer

In these cases you don t want Json to close the document

louiscad · Answer

True Do you know if that function from kotlinx serialization actually closes the stream

mbonnin · Answer

Looking quickly at the source it doesn t seem so

mbonnin · Answer

Back to the initial point Naming functions `useFoo ` isn t great either because it doesn t say anything about how it s going to use it

louiscad · Answer

What if you call the function twice Does it still work

mbonnin · Answer

Will try

louiscad · Answer

Then just let folks wrap it with `use ` when it makes sense

mbonnin · Answer

Sure but if my function closes it there s no need

louiscad · Answer

If the use case is that no one should need to let it non closed makes sense to use `use` inside no matter the naming or the signature

mbonnin · Answer

The use cases is that given a generic `decode InputStream ` function I want to know if I should wrap in `use `or not The current way seems to rely on the documentation or just guess like in the Json case

louiscad · Answer

To me it s more like will I use the same instance more than once

mbonnin · Answer

Yea but that s more or less the same thing right Can I continue using the same `inputStream` after the `decode` call or not

mbonnin · Answer

```Unexpected JSON token at offset 68 Expected EOF after parsing but had instead JSON input kotlinx serialization json internal ArrayAsSequence 61a002b1 kotlinx serialization json internal JsonDecodingException Unexpected JSON token at offset 68 Expected EOF after parsing but had instead JSON input kotlinx serialization json internal ArrayAsSequence 61a002b1``` Looks like `decodeFromStream` is doing yet something else sweat smile

mbonnin · Answer

It doesn t close but expects the end of file thinking face

louiscad · Answer

Is there an overload that takes something different than an `InputStream` from `<http java io|java io>`

mbonnin · Answer

Don t think so the `InputStream` support is pretty new IIRC

louiscad · Answer

Maybe you can make your own InputStream backed InputStream that emits a fake EOF when the boundary you want is reached

mbonnin · Answer

Mmmmm that sounds dangerous

mbonnin · Answer

Also that would emit the EOF after the Json object is finished parsing which requires Json parsing

louiscad · Answer

Isn t `InputStream` an interface

mbonnin · Answer

Sure but it means decoding Json twice

mbonnin · Answer

That s super bad

louiscad · Answer

If it s json withing another document like a markdown file you can detect the closing ```

mbonnin · Answer

Sure but I don t want to I want kotlinx serialization to do it for me slightly smiling face

louiscad · Answer

First time is just doing an indexOf iteration it s not json parsing in any way

mbonnin · Answer

I don t think there s a point in forcing the trailing EOF I ll file a bug

louiscad · Answer

Which is why kotlinx serialization doesn t do it it s not designed to detect when the input stops looking like JSON

mbonnin · Answer

Stilli wasted CPU cycles

mbonnin · Answer

kotlinx serialization assumes trailing EOF <https github com Kotlin kotlinx serialization blob 471f4bbfa28d0dd1d4af869dc992d7604374e4ac formats json commonMain src kotlinx serialization json internal lexer AbstractJsonLexer kt L160|https github com Kotlin kotlinx serialization blob 471f4bbfa28d0dd1d4af869dc992d kotlinx serialization json internal lexer AbstractJsonLexer kt>

louiscad · Answer

Not necessarily the logic to find ``` is more more simple than JSON parsing itself

mbonnin · Answer

Which is why you can t resume parsing the same inputStream

mbonnin · Answer

gt the logic to find ``` is more more simple than JSON parsing itself It is but if you have to parse json in all cases you don t want to waste cpu cycles searching for bacticks at the same time

louiscad · Answer

Since an InputStream can come straight from network I don t think you can always read the same instance twice

mbonnin · Answer

I m not talking rewinding I m talking continuing reading the same stream

mbonnin · Answer

``` Serializable class SimpleObject val name String Test fun testDecode val inputStream = name Object1 name Object2 trimIndent byteInputStream println 1 println Json decodeFromStream lt SimpleObject gt inputStream name println 2 println Json decodeFromStream lt SimpleObject gt inputStream name ```

louiscad · Answer

Iterating itself is not very expensive it s the operations done during the iterations that can cost

mbonnin · Answer

not very expensive is still gt free

mbonnin · Answer

I want everything for free

mbonnin · Answer

stuck out tongue

louiscad · Answer

Then use C and you will pay your calls to `free`

mbonnin · Answer

Yea I m ok paying for my garbage collector stuck out tongue

louiscad · Answer

I d measure the cost of iterating once to find the backticks and a second time for json parsing vs some code that manages both Ensure you re using custom code for parsing to measure the same thing

mbonnin · Answer

I ll just file a bug slightly smiling face

mbonnin · Answer

Because it s not only about cost it s also about API design

louiscad · Answer

To ask for EOF to be optional That d suit your needs fully

mbonnin · Answer

I want `decodeFromStream` to either parse a complete Json stream and close it or allow parsing partial Json streams and leaving them open

mbonnin · Answer

The current behaviour has the drawbacks of both approaches

mbonnin · Answer

Caller has to remember to wrap in `use ` or else leaks happens And at the same time it s not possible to decode partial streams

louiscad · Answer

Waiting for the GitHub issue link like a hedgehog

louiscad · Answer

mbonnin · Answer