Profunctor instance for `Codec` about autodocodec HOT 3 CLOSED

@solomon-b Where does Profunctor live? If it's here: https://hackage.haskell.org/package/profunctors, the answer is "because of the dependency footprint".
If you find a use-case for the instance, I'd like to see it!

from autodocodec.

This may be due to a misunderstanding of how to to use the library. I wanted dimap so that I could "lift" an instance into a newtype wrapper without affecting the final API shape:

newtype ForeignKeys = ForeignKeys { unConstraints :: HashMap ConstraintName Constraint }
  deriving stock (Eq, Ord, Show, Generic, Data)
  deriving anyclass (NFData, Hashable)

instance HasCodec ForeignKeys where
  codec = dimapCodec ForeignKeys unConstraints $ codec @(HashMap ConstraintName Constraint)

It would be nice if we could deriving newtype HasCodec.

from autodocodec.

Hey @solomon-b I think you're understanding how the API works correctly. (You don't need the type application, but I imagine it's there for clarity.)
I haven't been able to implement something that would make deriving newtype HasCodec work, but it sounds unrelated to Profuctors.
Please correct me if I'm wrong because I would like that too.

from autodocodec.