[master] Don't fill ForeignPtrContents field with bottom

[bgamari]

As noted in GHC #17290, ForeignPtrContents really should be strict.
With the addition of the FinalPtr constructor we now have a
sensible value to use in nullForeignPtr other than bottom.

Moreover, another unrelated GHC change (#17760) recently forced
the application of strictness for ForeignPtr's ForeignPtrContents
field. Consequently, we are making this change now. Unfortunately this
means that all earlier versions of bytestring will be unbuilable with
GHC >=9.0.

[sjakobi]

Unfortunately this
means that all earlier versions of bytestring will be unbuilable with
GHC >=9.0.

This doesn't sound very problematic to me. The vast majority of users probably just use the bytestring version that is bundled with GHC. A few others may use a more recent version. I don't see why anyone would want to use an older bytestring version.

[hsyl20]

LGTM.

[lehins]

Would it be possible to backport this change of few lines and making a minor release bytestring-0.10.13.0. I think this would allow packages with upper bound bytestring < 0.11 be still buildable with ghc-9

This would at least make this transition 0.10 -> 0.11 a bit less painful.

[sjakobi]

Would it be possible to backport this change of few lines and making a minor release bytestring-0.10.13.0. I think this would allow packages with upper bound bytestring < 0.11 be still buildable with ghc-9

I think this could be done. It takes just a bit of effort.

This would at least make this transition 0.10 -> 0.11 a bit less painful.

Can you say more about the pain? Why do you need to build an old bytestring with GHC >= 9?

[lehins]

Thanks to PVP there are a whole bunch of packages on hackage that have dependencies along those lines:

- bytestring < 0.11
- base == 4.*

If I depend on such a package I will no longer be able to use it together with ghc-9 despite that it would work just fine with new base.

I am just being realistic, it will take on the order of months or even years for many packages to update their upper bounds on bytestring package. Some of them will probably never update those bounds, because maintainer no longer cares. A good example is upper bound on random < 1.2, here a small subset of such packages three months after the release: commercialhaskell/stackage#5474

But, if we allow building older bytestring with newer ghc, we will at least let those packages to still be usable.

[Bodigrim]

@lehins good idea! I think it can even go as a patch release 0.10.12.1, because there is no behaviour change for GHC < 9.0. But let's postpone it until GHC 9.0 is certainly released, just in case of any additional breaking changes.

[lehins]

Yeah, postponing is a good idea, it will also give a bit more motivation for library maintainers to actually put some effort into updating bounds for their packages ;)

I think it can even go as a patch release 0.10.12.1

Only thing against that version I have is inability to specify such version difference with CPP with respect to 0.10.12.0, which can be very useful in this particular situation that deals with compatibility.

[sjakobi]

A minor compat release after GHC 9.0 sounds like a reasonable idea to me. 👍