What is an example of a use case where relying on the current behavior would be a good thing?

For an exception to happen, one has to force more than what was already forced when the handle was closed. The vast majority of instances of this---as far as I can tell---are people immediately closing handles they've lazily read from, and an exception is probably more informative than the empty input they currently get.

For correct-given-the-current-spec code to break, it seems like it would have to be relying on one part of the code forcing the input before closing to be an implicit signal to another part of the code that inspects the input after the closing. But I don't see a reason to encourage/support that kind of design.

I'm in favor of this change, in case that wasn't obvious. :)



On Fri, Jul 25, 2014 at 12:05 AM, Eric Mertens <emertens@gmail.com> wrote:
-1

I think that this change would make otherwise reasonable uses of hGetContents on large files more likely to end with an exception. It seems perfectly reasonable to use hGetContents to stream data from a either a large source or an infinite source (say a pipe or socket or /dev/urandom). Perhaps you're streaming those bytes into another form, who knows. In any case, file descriptors are precious and it would make sense to hClose the file when you're done with it rather than wait and hope that the GC gets to closing your file.

With this change we'd be introducing asynchronous minefields into code that don't need to exist.


On Thu, Jul 24, 2014 at 8:50 PM, John Wiegley <johnw@newartisans.com> wrote:
+1 from me.

John
_______________________________________________
Libraries mailing list
Libraries@haskell.org
http://www.haskell.org/mailman/listinfo/libraries



--
Eric Mertens

_______________________________________________
Libraries mailing list
Libraries@haskell.org
http://www.haskell.org/mailman/listinfo/libraries