
On Tue, Apr 3, 2012 at 2:50 PM, Simon Meier
2012/4/3 Duncan Coutts
: Actually, I think it doesn't make sense to provdide unsnoc for lazy bytestring at all. It's a bit of a silly operation for lazy bytestrings for the same reason as for lists. It's reasonable for strict bytestrings because you have the same access to the end of the string as the beginning, but the same is not true of lazy bytestrings.
I agree. I don't see a usecase for unsnoc on lazy bytestrings in production code.
It nevertheless might make sense to provide it for one-off scripting code and for interface consistency. The necessarily bad implementation shows in the runtime given in the comment. Hence, I'd marginally vote for inclusion of the lazy bytestring unsnoc.
Agreed on the interface consistency comment; also it's worth remembering that what type of bytestring you use is sometimes the choice of the library you want to work with, rather than yours :) An explicit warning in the docs, maybe, but keep it in there nonetheless. yrs, Ben