Kind of `Env`'s type variable

[endgame]

    Seems somewhat arbitrary to the naive reader (ie. me) parameterising over some `f :: Type -> Type` when you could just define:

data EnvF auth = Env {
    ...,
    auth :: auth,
} deriving stock (Functor, ...)

type Env = EnvF (Identity Auth)

And pass parameters as:

retryRequest ::
  forall m a f.
  ( Foldable f
  ) =>
  EnvF (f Auth) ->
  a ->
  m (Either Error (ClientResponse (AWSResponse a)))

_Originally posted by @brendanhay in https://github.com/brendanhay/amazonka/pull/875#discussion_r1064127139_

[endgame]

If we use a type variable of kind Type, we either:

• Take in EnvF Auth and EnvF (), but then it gets fiddlier to have a single httpRequest function which send a request and signs it if possible (maybe add a typeclass?);
• Take in EnvF (f Auth), but then it's surprising when EnvF Auth fails to typecheck and not really clear that the fix is to use EnvF (Identity Auth). A possible plus is that EnvF (Maybe Auth) is permitted, but a key benefit of the Env' withAuth design is that it's immediately clear from the type whether or not the Env' has an Auth and we can write sendUnsigned to work over any Env', but send needs an Env' with credentials.

I still think that the Type -> Type parameter is the correct tradeoff, but perhaps it's possible to make the rationale clearer? Note that the non-.hs-boot file has type Env = Env' Identity and type EnvNoAuth = Env' Proxy aliases, each with haddocks.

[endgame]

It's been a couple of months and I still agree with everything I wrote here. Since nobody's felt strongly enough to comment about wanting to do something else, I'm going to close this. We can reopen the discussion if there are strong feelings and a compelling alternative design.