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

On Sun, Nov 11, 2012 at 08:22:08PM +0100, Bas van Dijk wrote:

On 11 November 2012 15:34, Herbert Valerio Riedel 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