implicitly[GroupDecoder[CC4]]was never going to work. You can have a
MatchDecoder[CC4], but not a
GroupDecoder. Do you need me to explain why?
MatchDecoderdecodes a match - potentially many strings
([a-z]+) ([0-9|-]+)has two groups: the first one, at least one letter, and the second one, at least one digit
GroupDecoder[A]is essentially a
String => Awhere a
Seq[String] => A
Bin order to derive a
MatchDecoder[(A, B)]. Since
CC4cannot have a
GroupDecoder, you cannot get a
MatchDecoder[(CC4, B)]for any
yep that part I get
but conceptually speaking there is not much difference in my eyes between something like ((A, B), (C, D)) and (A, B, C, D).
so that's why I would think that .evalRegex[((A, B), (C, D)) could work just as .evalRegex[(A, B, C, D)] works
but you don't have to answer this immediately
I played around with this a bit and here is one idea that works quite cleanly in the current model:
(I also had another idea where matchdecoders could be represented as a list of groupdecoders but that would require a lot of breaking stuff in the current implementation)
but for the progressed match gist: if there is a way to know how much of the matches a decoder will take from the matcher then the implicit could be generalized to more arbitrary shapes.