I'm in favor of removing it entirely. Making it an alias may help people who want to keep code compatible with base < 4.7, but it could also introduce some confusion. Some thoughts:

- It doesn't help people who want to write a `Bits` instance for their data type. That will still require CPP.
- People writing bit-type-polymorphic code will have to upgrade to FiniteBits when using newer base, which will force CPP for compatibility anyway.
- People writing bit-type monomorphic code don't even need this function, since they can just write out the number of bits (except for with Int and Word, whose sizes vary by platform).


On Sun, Feb 4, 2018 at 4:15 PM, David Feuer <david.feuer@gmail.com> wrote:
Quite some time has passed since I first raised this question. There
doesn't seem to have been much discussion, but we really need to do
something! Just leaving bitSize as deprecated seems like the worst
option. Does anyone else have anything to add?

On Mon, Jul 10, 2017 at 11:50 PM, David Feuer <david.feuer@gmail.com> wrote:
> The long-deprecated bitSize method of the Bits class is slated to be
> removed in base-4.11 (GHC 8.4). There is one remaining question:
> should we replace it with a *function* by that name with a FiniteBits
> constraint? I don't feel very strongly either way, but Ryan Scott
> seems in favor and Edward Kmett seems opposed. So it seems best to
> bring it to the libraries list and let the CLC make the call. If the
> function is added, it would look like this:
>
> bitSize :: FiniteBits a => a -> Int
> bitSize = finiteBitSize
>
> The biggest downside I see is that we might one day want to reuse the
> name for something with a better type, such as
>
> bitSize :: forall proxy a. FiniteBits a => proxy a -> Int
> bitSize _ = finiteBitSize (undefined :: a)
>
> or
>
> bitSize :: forall a. FiniteBits a => Tagged a Int
> bitSize = Tagged (finiteBitSize (undefined :: a))
>
> or (with type applications)
>
> bitSize :: forall a. FiniteBits a => Int
> bitSize = finiteBitSize (undefined :: a)
>
> Thanks,
> David Feuer
_______________________________________________
Libraries mailing list
Libraries@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries



--
-Andrew Thaddeus Martin