<div><div dir="auto">If the Control.DeepSeq module exports an error-yielding instance, then one would need to newtype all their ForeignPtrs in order to define their own correct NFData instance. Naturally I’m biased, but that seems like quite a hoop to jump through to get correct but subtle behavior. I’m not sure the core libraries go to such lengths to hide correct-but-tricky behavior anywhere else; I’d be interested in seeing existing examples of this.</div></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jan 15, 2020 at 1:13 AM Henning Thielemann <<a href="mailto:lemming@henning-thielemann.de">lemming@henning-thielemann.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
On Wed, 15 Jan 2020, Travis Whitaker wrote:<br>
<br>
> If such an error-yielding instance were added, how would users who need <br>
> the correct-but-potentially-confusing behaving NFData instance cope with <br>
> this?<br>
<br>
In the criterion/record example they would manually implement the NFData <br>
instance for the record, as you already suggested.<br>
</blockquote></div></div>