[GHC] #12970: Add default implementation for Bits.bitSize

[GHC]

#12970: Add default implementation for Bits.bitSize
-------------------------------------+-------------------------------------
        Reporter:  txnull            |                Owner:  dfeuer
            Type:  feature request   |               Status:  patch
        Priority:  high              |            Milestone:  8.4.1
       Component:  libraries/base    |              Version:
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):  Phab:D3723
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by hvr):

 Replying to [comment:11 bgamari]:
 > Are we going to do this? If so I wonder whether we should push it to 8.6
 to avoid breaking libraries again prior to 8.4.

 By that argument we'd never remove anything, as the same situation would
 just re-present itself during GHC 8.5; if maintainers have been ignoring
 the warnings introduced in GHC 7.8, they'll likely ignore them forever...
 life's too short... ;-)

 In comment:4 Ed wrote:

 > We deprecated `bitSize` back in 7.8. Removing it outright in 8.4 seems
 to be a reasonably measured move and would preempt the need for this
 default. I'm rather inclined to say we should just finish removing it.

 So that's the part I believe everyone agrees.

 And one year later, David submitted a patch (see comment:7) to finally
 finish this.

 However, David also brought up a suggestion of doing something that wasn't
 originally considered/planned: adding a top-level `bitSize` binding in
 place of the removed `bitSize` method.  It isn't clear whether this is
 something everyone agrees to want to do (David writes in phab:D3723:
 ''"@ekmett seems to oppose stealing the name."'').


 What I'd suggest at this point while we're still ahead of the GHC 8.4
 freeze: Do the removal now, don't add anything new in its place. Once GHC
 HEAD snapshots appear with this change, we'll see quickly how bad the
 fallout is.

-- 
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12970#comment:12>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler