Review API for conditionally defined items

[hvr]

I notice/realise we expose some instances that are defined based on base version despite them existing before the given base version. This is obviously a problem as it would violate the package abstraction in a non-benign way.

[RyanGlScott]

Which instances are you referring to? Are you talking about, say, the NFData instance for Array, which has a different context depending on the base version? Are you referring to instances like the one for Identity, which are only exposed conditionally based on the base version but have existed prior to that in transformers? Something else?

[hvr]

@RyanGlScott Among others, I noticed a couple of new NFData1 instances being added and guarded behind CPP. I'd just like to get an overview of the damage, and figure out whether to add some big visible documentation signpost in the haddocks, or even constraint the lower bound on base, in order to reduce the exposure to the risk. I was already planning to constraint to base >= 4.5 so we can finally get rid of some of the CPP... too bad new CPP was added in the meantime ;-)

PS: Of course, in the case of deepseq it's not as bad as I made it sound, since if ppl make use of Travis to check with all the base versions they declare support for, the risk is rather low for such mistakes (assuming a conditionally defined instance exists) sneaking onto Hackage.

[RyanGlScott]

Ah, #21 you mean. Here are all the conditionally defined NFData{1,2} instances that were introduced:

• NFData1 (Array a)/NFData2 Array (#if __GLASGOW_HASKELL__ >= 711)
• NFData1 Ratio (#if MIN_VERSION_base(4,9,0))
• NFData1 Down (#if MIN_VERSION_base(4,6,0))
• NFData1 Proxy (#if MIN_VERSION_base(4,7,0))
• NFData1 Identity (#if MIN_VERSION_base(4,8,0))
• A whole bunch of of datatypes brought over from semigroups (#if MIN_VERSION_base(4,9,0))

Down looks actually quite doable on all supported versions of base... I might whip up a PR to take care of that one.

[RyanGlScott]

What is the current status of this?