Michael Ilseman

Hello, I'm the original author of LLVM's SparseMultiSet and I've always wanted this functionality presented in Swift, but there's some design challenges I'm sure you're facing. I haven't thought about...

> We could constrain the key type (for a dictionary-like implementation) or the element (for a set-like implementation) with protocols. More specifically, we're interested in types that map to the...

> Could you explain a bit about how iterations and deletions are handled in LLVM's SparseMultiSet? LLVM's SparseSet is a pretty specialized data structure, and SparseMultiSet even more so. A...

> get_current_dir_name does seem better, but it requires _GNU_SOURCE and I'm not sure how swift-system deals with this. Hmm, however NIO handles it. @lukasa , do you know?

> We should lose the get prefix -- per the Swift API design guidelines, functions without side effects should read as noun phrases. I (weakly-held) liked the `get` in the...

We couldn't do `readAll` at the time. With opaque return types with associated type bounds we should soon be able to do a read all that returns `some Collection`. When...

> Do I assume that it's not appealing to have a wrapper that still deals with UnsafeMutableRawBufferPointer, one that just handles the while loop over the underlying read(into:)? `read(into:)` wouldn't...

`read(filling:)` makes sense to me if it will avoid the loop dance for use cases that want to read up to a fixed length from a file. E.g. they're doing...

> I've used libraries where the fill-this-buffer-by-reading-bytes operation would signal an error if it runs out of bytes and I used ones where it would return a partial buffer. Generally...

> given that we provide writeAll, it seems silly not to also have the equivalent operation in the opposite direction. Yes, but read goes in the opposite direction and we...