RFC: Can DefaultSignature compile-time conditional APIs be regarded "benign"?

[Ian Lynagh]

On Sun, Nov 11, 2012 at 08:22:08PM +0100, Bas van Dijk wrote:
> On 11 November 2012 15:34, Herbert Valerio Riedel <hvr at gnu.org> wrote:
> > I'd argue that there is no harm in allowing this kind of compile-time
> > conditional APIs using the DefaultSignature language extension.
> 
> I agree.
> 
> There's one minor issue: Say some client does not intend to rely on
> DefaultSignatures but forgets to write a definition for the method. He
> will then not get a "No explicit method or default declaration"
> warning. However, in this case I think the benefits outweigh this
> disadvantage.

If deepseq does not use DefaultSignatures, then clients must write

    instance NFData MyType where
        rnf = ... e ...

If deepseq conditionally uses DefaultSignatures, and a client wishes to
make use of that but still remain portable, then it must write

    instance NFData MyType where
    #if COMPILER_SUPPORTS_DEFAULT_SIGNATURES
        rnf = ... e ...
    #endif

which, even ignoring the fact that we don't have an easy way to get a
correct COMPILER_SUPPORTS_DEFAULT_SIGNATURES symbol at the moment, is
more typing, and would not result in better/faster code.

And worse still, if someone with a featureful compiler forgets to write
the instance body, they will get no warning that it will not work for
other users.

It's true that if the client's portability is <= that of
DefaultSignatures for other reasons then it could omit the instance
body, but that feels like a dangerous direction to head in to me. And
it would not be much more effort to write

    instance NFData MyType where
        rnf = genericRnf

(where genericRnf is exported by the deepseq package).


I think deepseq should either unconditionally use DefaultSignatures, or
not use them at all. At this point, my preference would be the latter.


Thanks
Ian