Data.Bits can still have default implementations for testBit, bit, and popCount by using -XDefaultSignatures

[joeyadams]

In commit f99cee0 of the base package, the Num constraint was removed from the Bits class. Because the default implementations of testBit, bit, and popCount required Num, the same commit made them external functions instead.

We can still have default implementations for these if we use the -XDefaultSignatures GHC extension:

#ifdef __GLASGOW_HASKELL__
    default bit :: Num a => Int -> a
    bit = bitDefault

    default testBit :: Num a => a -> Int -> Bool
    testBit = testBitDefault

    default popCount :: Num a => a -> Int
    popCount = popCountDefault
#endif

Whether we want to do this or not, I'm not sure.

Pro:

• This is more convenient.

• This may prevent people from encountering runtime errors in existing code that does not have bit, testBit, and popCount implementations, where the author forgot to compile with -Wall .

Con:

• Users get away with writing less portable code, so those who do wish to use non-GHC will have more support work to do.

The attached patch adds defaults for testBit, bit, and popCount, for GHC only. It does not update the documentation, though, so "Minimal complete definition" as-is would be misleading.

P.S.: This ticket is for GHC 7.6.1-rc1. That version tag is not available, though.

[joeyadams]

Data.Bits: Use -XDefaultSignatures to have default instances for bit, testBit, and popCount

[pcapriotti]

The patch looks good, thanks.

[igloo]

We discussed using this extension at the time, e.g. in  http://www.haskell.org/pipermail/libraries/2011-October/016909.html but decided against it.

[jwlato]

I would request that you reconsider this decision. popCount was only added to the Bits class in base-4.5, which means that now Bits implementors are stuck in the following undesirable position:

1. omit popCount, which may lead to runtime crashes if popCount is used in programs compiled with ghc-7.6 2. define popcount and drop support for ghc < 7.4 / base < 4.5\ 3. use CPP or cabal trickery to support ghc-7.2, ghc-7.4, and ghc-7.6

For users who wish to support the three most recent ghc versions, none of these are good options.

Upon reading the thread in libraries, I don't believe that anyone realized this issue at the time.

[jwlato]

Apologies, I meant to re-open this issue before and forgot. I'm re-opening due to the issue described in my 2012-08-14 comment.

[igloo]

I still think the decision was right. If you disagree, please make a new proposal on the libraries list.

[igloo]

(see  http://www.haskell.org/haskellwiki/Library_submissions for details)