Ryan Scott

Oops, I misspoke about `bimap f id`, then.

My first impression is that `Bilift` seems like a sensible thing to have. After all, we have `Applicative` transformers, so why not `Biapplicative` transformers? If you'd care to whip up...

True. I see two options: 1. For consistency with `Lift` from `transformers`, we just make it `instance Biapplicative f => Biapplicative (Bilift f)`. This is a stronger constraint than is...

@ekmett deliberately chose the current design, see https://github.com/ekmett/bifunctors/pull/8#issuecomment-121932733. That being said, perhaps there's room for this incarnation as well (under a different name).

> (#12369 has been implemented) Great! FWIW, I doubt we are going to be seeing any return-kind-polymorphic data families put into this package any time soon due to `bifunctors`' wide...

In any case, I'm not sure what exactly is being proposed here anymore. There seem to be any number of possible changes that @Icelandjack is hinting at: 1. Changing the...

This issue has not been resolved, although some of the code described in https://github.com/aws/s2n-tls/issues/3080#issue-1015463448 shuffled around in #3155. In particular, the code which assumes that `conn->client_session_resumed` is disabled now lives...

@yigitozkavci, this package has pretty much ceased active development. I recommend using [`llvm-hs`](https://github.com/llvm-hs/llvm-hs), a fork of this project which is actively maintained.

This is actually a GHC issue in deep disguise. The issue is that on GHC 8.6, `QuantifiedConstraints` can't be headed by the `(~)` type constructor—see [Trac #15359](https://ghc.haskell.org/trac/ghc/ticket/15359). (The error message...

I take it this issue can be closed, then?