StringParser for value classes

[mbore]

It would be great if these would make it to the library. I know that I shouldn't create an implicit function in rho.bits.StringParser, but if somebody points me to the right place I'll open a PR with this

implicit def parseAnyVal[T, U](implicit tt: TypeTag[T],
                                 ev: T <:< AnyVal,
                                 unwrapped: Unwrapped.Aux[T, U],
                                 parser: StringParser[F, U]
                                 ): StringParser[F, T] = new StringParser[F, T] {
    override def parse(s: String)(implicit F: Monad[F]): ResultResponse[F, T] =
      parser.parse(s).map(value => unwrapped.wrap(value))

    override def typeTag: Option[TypeTag[T]] = Some(tt)
  }

[zarthross]

I'm open to the change, but I want to be cautious about it's implicit placement...

I can think of many cases when wrappers are constructed using AnyVal like refined does, where we want to force the user to use a 'safe' constructor, and this parseAnyVal would break their compiler check... their wrapper would work, but produce unsafe results.

[mbore]

I agree. What do you think about separate module rho-extras in which we could create RefinedParser (addressed in #260) and AnyValParser ?

[zarthross]

Rather than having an extras module, I think refined support deserves its own module entirely.

With Refined it would be simple enough to provide a StringParser for all refined instances since it has a specific way to run the verifications... that's not really the case with AnyVal. There is no standard way to run the apply/build/wrap etc method, and no standard output... So I really hesitate to make a blanket implicit... I'm biased toward forcing the creator of the AnyVal to produce the string parser themselves.

[zarthross]

After thinking about this, I don't think we want to add this kind of support at this time.