You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Lazy.length s must force the entirety of s, while (by design) Lazy.compareLength s 10 stops after finding at least 11 words. And yet we try to rewrite Lazy.length s > 10 to Lazy.compareLength s 10 == GT. I can't quickly think of any "reasonable-looking" example where this change will actually cause problems, but I am deeply skeptical of a rewrite rule that silently changes strictness behavior in this way, especially since it is common for forcing a lazy bytestring to mean performing deferred I/O actions.
(Also, Int64 overflow can happen in Lazy.length but not in Lazy.compareLength, though it's probably only possible to actually observe that difference in behavior by doing something rather stupid.)
The text was updated successfully, but these errors were encountered:
I still prefer killing the rules, but it's not a battle worth fighting. And if we aren't removing these rules then I don't consider this important for 0.12.0.
Lazy.length s
must force the entirety ofs
, while (by design)Lazy.compareLength s 10
stops after finding at least 11 words. And yet we try to rewriteLazy.length s > 10
toLazy.compareLength s 10 == GT
. I can't quickly think of any "reasonable-looking" example where this change will actually cause problems, but I am deeply skeptical of a rewrite rule that silently changes strictness behavior in this way, especially since it is common for forcing a lazy bytestring to mean performing deferred I/O actions.(Also,
Int64
overflow can happen inLazy.length
but not inLazy.compareLength
, though it's probably only possible to actually observe that difference in behavior by doing something rather stupid.)The text was updated successfully, but these errors were encountered: