[PROPOSAL] Adding Generics-based DefaultSignature to `deepseq` package

[Edward Kmett]

On one hand, the change is a path to a better deepseq that is more correct.

On the other hand

1.) It does change the semantics of existing code.

2.) It does cause existing code that works to break if they don't supply a
Generic instance or a manual default.

Admittedly:

#1 happens by making it more strict, which is what we want in the case of
NFData, for once.
#2 is something that is easily rectified and makes the resulting code more
robust/useful anyways. Folks who don't want to lean on generics have the
option to just write the rnf x = seq x () default, so nobody is being
forced to lean on the extension.

I'm somewhat on the fence about this, because I don't like silent semantics
changes, but as it is only happening by making things more strict *in the
one place in the language* where that is the very point, you can consider
me weakly +1.

-Edward


On Thu, Oct 16, 2014 at 1:09 PM, Andres Löh <andres.loeh at gmail.com> wrote:

> > The Proposal
> > ============
> >
> > I hereby propose to merge `deepseq-generics`[2] into `deepseq`[1] in
> > order to add Generics support to the `NFData` class based on the
> > `-XDeriveGenerics` and `-XDefaultSignature` language extensions.
> >
> > A concrete patch is available for bike-review at [3]
>
> +1
>
> Cheers,
>   Andres
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20141016/481ebe29/attachment.html>