Louis Wasserman

In particular, this should deterministically succeed: ``` flow { emit(1) throw Exception() }.iterate { iter -> while (iter.hasNext()) { if (itr.next() % 2 != 0) return@iterate true } false }...

Let me demonstrate the difference with some diagrams and some Kotlin Playground demos. It might be a difference you consider "essentially the same thing," but we've found it matters a...

I'm not sure I follow why it's not plausible to write, for example, ``` flow { repeat(10) { A().use { emit(it) } } } ``` or ``` fun Flow.closing(): Flow...

It was a deliberate choice not to expose these for public use. It wasn't clear we wanted to get into the business of "alternate collection implementations for different performance goals,...

This is difficult without a DiscreteDomain. Your current implementation would treat [0, 1) and (0, 1] as overlapping, even though there aren't actually any integers in their intersection.

MessageDigest includes, but is not limited to, MD5.

`HashFunction` is an interface with many implementations, including those three (`Hashing.md5()`, `Hashing.sha1()`, `Hashing.sha256()`). Those three are backed by MessageDigest; the others are not.

The point is that we don't expose a utility in _general_ to allow any `MessageDigest` algorithm to be used as a `HashFunction`.

No, there's no plan to change other implementations of `HashFunction`. This issue is just about whether or not we should expose a way to make a `HashFunction` from any `MessageDigest`.

My first reaction is that the current semantics make some sense: an entry still being computed isn't really in the cache; it's not really there to be invalidated?