Implement unchunks (inverse of chunks)

[armanbilge]

This seemed a strange omission to me, but maybe there's a good reason for it?

[mpilquist]

There's already unchunk which (unfortunately) does something different and we never found a name that we were happy with.

[djspiewak]

The only concern I see is the fact that unchunk is a function which you almost never want to touch, while unchunks is a perfectly normal thing that you'll do all the time. :-P

[armanbilge]

The only concern I see is the fact that unchunk is a function which you almost never want to touch

If this is true, can we deprecate and rename unchunk? Would deprecation be enough warning when writing new code, is this really the method you want to use?

[mpilquist]

I'd be fine with deprecating unchunk and giving its replacement a scarier name like destroyChunks or unitaryChunks or something?

[armanbilge]

It's a very obtuse method actually, because the change is happening under-the-hood right? What are its use cases? I would guess maybe when you don't want eager evaluation, so you don't lose a whole chunk on error? Could the name reflect something about that?

[djspiewak]

Yeah I've used O.G. unchunks like… once… The use-case is when you have a downstream flatMap which produces considerably more data on a per-element basis. If you don't unchunk in that case you can have memory issues.

[armanbilge]

Another idea: if the OG unchunk use-case is so rare, why don't we just suggest replacing with .chunkLimit(1).unchunks?

I think this makes it even clearer exactly what is going on.

[djspiewak]

Another idea: if the OG unchunk use-case is so rare, why don't we just suggest replacing with .chunkLimit(1).unchunks?

This is superb.

[mpilquist]

With current implementation of chunkLimit, that will be a bit different (compare expanded form of uncons1 with unconsLimit(1)) -- we should probably fix that

[armanbilge]

@mpilquist excuse my density, what exactly is the difference?

[mpilquist]

The special casing which avoids the cons call when chunk size is equal to 1

[armanbilge]

I still don't see how that makes a difference, other than performance? Since cons will ignore an empty chunk.

[mpilquist]

Only performance, though if full expansion is literally only the call to cons and doesn't actually change anything, then disregard

[armanbilge]

The special case avoids the cons and the drop/splitAt. I can make this change?

[armanbilge]

But btw, how important is performance here anyway? In @djspiewak's use-case if the stream is about to get slammed by flatMapping to big chunks does this really matter?

[mpilquist]

This should have introduced a bunch of deprecation warnings in the test suite. Can we address those too?

[armanbilge]

On it.

[Daenyth]

I've wanted this since Segment was still a thing