Consider dropping Data.Has

[akhra]

trafficstars

I keep running into issues arising from Has, and especially its interplay with the concrete HasFoo class idiom. Today this culminated in encountering a runtime loop on code that shouldn't even typecheck (trivial reproduction here). This has thoroughly convinced me that @snoyberg chose the more stable path with RIO, and I've now fallen back to exclusively using HasFoo (with the exception of one instance Has ModHttpClient AppEnv since that's required to use the API).

[valpackett]

HTTPClient does not import Data.Has and uses HasHttpManager in MonadHTTP, so you can use Network.HTTP.Client.TLS.newTlsManager directly instead of newHttpClient.

I've extracted Has stuff into a separate module.

If all these HasFoo classes already had instances for tuples, I guess we wouldn't actually need Has…

[akhra]

If all these HasFoo classes already had instances for tuples

Good point. And generating those is arguably within the scope of commercialhaskell/rio#113. I'll try to take another whack at that soon.

[mitchellwrosen]

generic-lens is like has++ ;)

type MyEnv = (Fooby, Barby, Bizzy)

whop :: RIO MyEnv Response
whop = do
  fooby <- view (the @Fooby)
  ...