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

Ian Lynagh ian at well-typed.com
Sun Nov 11 20:59:03 CET 2012


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




More information about the Libraries mailing list