Open parsonsmatt opened 2 years ago
I remember a similar issue a while ago with for_
I think.
I'm about -0.5 on this proposal. It's a breaking change, which I'm generally against. It also deviates away from base
further and makes the standard function slightly less useful. Given that this is an upstream issue as well, patching it here seems like it's just hiding a footgun, since any library you use may decide to use a forever
from base
that has this issue. It seems like education would be a better option here.
An alternative I'm slightly less bothered by would be putting a WARNING
on forever
, and then exporting both foreverM
and foreverA
with docs to explain why you would want one versus the other.
The WARNING
approach sounds good to me - a great way to do education by API design :) I can work up a PR if you'd like.
That would be great, thanks!
Currently
ClassyPrelude
exportsforever
as defined inbase
.The
forever
space leak is documented here, along with links to discussion and other reports. The issue is that the default implementation of*>
is:And, unless you specifically define one of
(<$)
or(*>)
, then the implementation offorever
will cause a space leak.resoucet
is subject to this, and I suspect thatHandlerFor
is as well. Those types useDeriveFunctor
, which may avoid the issue.I'm proposing that this library export:
This should prevent this footgun from impacting users of this library.
EDIT:
HandlerFor
does not have this issue