Get rid of `data-array-byte`

[MaximilianAlgehed]

This "standard" solution is not even supported by stack LTSs. If people want to run ancient GHC versions with recent QuickCheck versions and the latest-and-greatest base features that sounds like a them problem.

[Bodigrim]

Just a friendly reminder that removing any instance constitutes a breaking change and requires a major version bump. Me and many other people just went through a cycle of updates to their packages to accomodate QuickCheck-2.17 and frankly doing it again any time soon for a potential QuickCheck-2.18 would be quite disheartening.

If you feel so strongly about data-array-byte and if you don't care about people using ancient GHC versions, please consider just dropping support of GHC < 9.4.

[MaximilianAlgehed]

I'm well aware.

We're going to have to discuss this among the maintainers. The precise problem we feared materialized: the supposedly standard solution wasn't so standard after all and will cause headaches downstream for people e.g. on stack. It also comes with the added risk of having to pick sides when the inevitable controversy happens over a future compat package.

If we change this we're going to bake it in with other breaking changes. But I don't see us dropping support for older GHCs because of it. There is a legitimate use-case for older GHCs still.

[phadej]

Most people using stack won't upgrade (to a new major version of) QuickCheck until there is a new snapshot with new QuickCheck. Going out of a snapshot has been and always be unpleasant experience with snapshot based dependency resolution paradigm.

[Bodigrim]

the supposedly standard solution wasn't so standard after all and will cause headaches downstream for people e.g. on stack.

I’m curious to learn more about scenarios, in which it causes a headache. data-array-byte first appears in Stackage LTS 20.1, GHC 9.2. So presumably we are talking about someone on Stackage LTS 19 and GHC 9.0 who nevertheless wants extra-deps: QuickCheck-2.17. In such case a) adding data-array-byte to an already nonempty list of extra-deps does not sound excessive and b) probably is the least of complications to overcome, because such a recent version of QuickCheck will entail many other extra-deps starting with aeson.