Implement optional implicit allowing usage of circe decoders without EntityDecoder definition

[Leammas]

I've discussed the necessity of this implicit in gitter. Appeared useful.

[rossabaker]

I think this is useful, but it's worth mentioning two reasons that this is not a default, and maybe even worth mentioning this in the docs.

1. Many APIs support multiple representations. There's one reasonable way to render a Json, but there can be multiple reasonable ways to render a Foo.

2. This introduces incoherent instances. For instance, now we have two EntityDecoder[F, String]. It surprises people which one wins.

If that doesn't scare people off, this technique is often useful.

I don't see any reason not to do an Encoder where we do the Decoder. And in that case, it'd be nice to not require two imports.

[Leammas]

The first point is already mentioned in https://github.com/http4s/http4s/pull/1917/files#diff-dcf0079785763cffc8cb901dad9f0628R205 Should I clarify it?

And I doubt that incoherent instances are possible in the same scope: they result in ambiguous implicits error.

[rossabaker]

I looked at the diff, and not the wider context. You're right, I think the first point is covered well enough.

As for the second issue, a lexically scoped instance (e.g., import CirceEnityDecoder._) has higher priority than an implicitly scoped instance (e.g., one found on the companion of EntityDecoder). So the issue here is that Ok("foo") compiles with or without this new import, but the behavior varies. It's fine as long as people know the ramifications, but it's a situation that I personally prefer to avoid.

[Leammas]

I tried testing the implicit resolution and found that it does not compile at all. Somehow EntityDecoder from companion and generic one got the same priority.
Here's the repro: https://github.com/Leammas/http4s/blob/4f114c4ecccc3ab01a6b0491968056de527cdd5c/circe/src/test/scala/org/http4s/circe/CirceSpec.scala#L191

[ChristopherDavenport]

Why do this as a trait and then an object which extends said trait? Why not just place this in the object?

[Leammas]

I use it in combined object org.http4s.circe.CirceEntityEncDec now and there's a small probability that someone may find it useful for its own generic code.

[Leammas]

I added implementation allowing usage of EntityEncoder in the same way and the single import mentioned by @rossabaker

[rossabaker]

I think Codec is a more common term than EncDec. How about CirceEntityCodec?

[Leammas]

Yeah, sounds better.

[rossabaker]

This tut broke with an ambiguous implicit. We need to sort this out. Running sbt doc/tutQuick should test it locally.

[Leammas]

Woops, the exact thing I wrote: we can't use both CirceEntityEncoder and plain json. I restricted the scope, but I'm not sure if it's the right way. Maybe I should not use tut:book there at all?

[rossabaker]

I think it's good to ensure that the import continues to compile, and you note the risk of ambiguity below. I played with invisible braces around it, and it doesn't work. I think the best we can do.

[rossabaker]

I can backport this into release-0.18 if we want to squeeze this into the release with the pool fix.