On Mon, Feb 28, 2011 at 2:57 PM, wren ng thornton
So then what would become of the string variants? Backwards compatibility and all... not _everyone_ uses ByteStrings yet.
If you need the String API, specify a dependency on a version of the package that still uses String. Also, FWIW, the real impetus behind writing these was to deal with lazy
ByteStrings, since that's what one of my dependencies uses[1].
What you really really want, then, is fdWriteAll, which repeatedly uses writev to write all of a list of strict (or a single lazy) bytestring to an fd, no? That's why I added sendAll to network-bytestring, because it's absolutely the common case that you want to write everything you can to a file descriptor, and not have to worry about short writes.
It seems like a common enough situation that it should be handled directly. Forcing people to call (BS.concat . BL.toChunks) first muddies up the code and introduces additional copying, whereas making people use (mapM_ fdWrite . BL.toChunks) is still rather messy and it's buggy in the face of partial writes.
Well, wait. That paragraph portion seems to confuse things. At the very least, it confuses me, because I surely didn't suggest using concat, as that would be silly. I want to see four entry points for writing: fdWrite :: Strict.ByteString -> IO Int fdWriteAll :: Strict.ByteString -> IO () fdWritev :: [Strict.ByteString] -> IO Int -- turn the list into an iovec, then call writev fdWritevAll :: [Strict.ByteString] -> IO () People would normally use the 'All' variants, but there are times when you really do want to know if you've performed a short write so that you can handle it yourself.