Ken Scambler

Here's another one, this time from an `index` call: ``` val i = summon[Index[Resource[?], List[String], Resource[?]]] server.focus(_.index(path)(using i)) ``` ``` Exception occurred while executing macro expansion. scala.MatchError: Skolem(165252930) (of class...

This is actually related to `Focus` not handling existential types gracefully, see #1201

``` case class Foo[T](content: Map[String, Foo[?]]) given Index[Foo[?], String, Foo[?]] = ... Focus[Foo[?]](_.index("abc")) // Can't resolve the given Index instance ```

Do we require a common method in the supertrait, or do we just scout around for fields with the same name & type in the case classes?

One of the earlier versions of the ticket had selection over different case classes without a supertrait method, but the usecase doesn't make any sense to me. I don't see...

I think my ideas are pretty aligned with yours. I'd say: Have "onion rings" of documentation levels, where each level n need not know anything about n+1. Something like: -...

Here's the culprit; Cats' Representable has an `index` extension method. https://github.com/typelevel/cats/blob/e0784fc0d95b9c4eed0bb1ddce6c69e3fd9a4a4f/core/src/main/scala/cats/syntax/representable.scala Git blame says it was added 3 years ago. We're part of the Typelevel/Cats family of stuff aren't we...

While `index` has been in Monocle since forever, it's only in Monocle 3 that we added the extension method as a way of mitigating the type inference penalty for overloading...

I think a breaking change is bad for users, and `idx` is a worse name and not in keeping with the direction of avoiding cryptic symbols and abbreviations. So I...

We could keep them in a mixin trait and get the optics to extend it?