r.close()here be properly captured? Is there really a need to do a
NonFatalpattern matching considering that any adequate monad shouldn't catch fatal exception? And is non-exhaustive matching intentional?
catchNonFatalshould be used only for side-effect free functions that can throw exceptions (e.g. they might divide by zero but shouldn't do
println) AFAIU, since it does
pure(a)which is strict in its argument and therefore executes whatever side-effects
a: => Amight have.
tailRecMisn't necessary stack safe when you have thousands of iteratees sequenced on a single chunk if the underlying
flatMapisn't stack-safe: #142. it's fixed in #141, but I'm not planning to backport it to an 0.6.2 unless someone is particularly interested, since it's somewhat unlikely people will run into this.
io.iteratee.files.SuspendableFileModule#readBytesFromStreamare not supposed to be consumed multiple times, right? I.e. if I create an
Enumeratorinstance and consume it in a certain way (e.g. taking
headof it), it doesn’t make sense to keep that instance, because I’ll not be able to consume it again.
Seq[Char]s all over the place.
Evalfor effect capture? suspicious eyes
Asynctype classes. You create an instance of a module and get file I/O enumerators, etc., and part of creating the module instance is that you have to handle effect capture.
Enumerator.liftMEval. I was skeptical about providing first-class support in core for effect capture for types like
Future, but Oscar talked me into a couple of concessions, and
liftMEvalis one of them.