Frank Thomas

@crypticmind Yes, that makes sense. But note that `F[String, _]` in the type parameters list should still be `F[_, _]` since `RefType[F]` requires that `F` is a binary type constructor.

Early versions of refined used `@@` exclusively because I thought using a well established tag type would be beneficial and that the subtyping relation `T

An easy target for removal are the `Subtype` and `Supertype` predicates. I think they have nearly zero practical relevance and are only there because they were easy to write.

With the recently added `refined-shapeless` module we could also move support for `shapeless.tag.@@` to this module. It would be then similar to the support of `scalaz.@@` that we currently have...

I should mention that I used the `Predicate` encoding in my experiment because it is much simpler than `Validate` which is current building block in refined. The idea was that...

This seems to work: ```scala object collection { type NonEmptyList[A] = List[A] Refined NonEmpty object NonEmptyList { class NonEmptyListOps[A] extends RefinedTypeOps[NonEmptyList[A], List[A]] { def fromCons(cons: ::[A]): NonEmptyList[A] = Refined.unsafeApply(cons) }...

Even `RefinementError` is not good enough. Suppose we have a predicate `A And B`. How do I know if only `A` failed, only `B` failed or both failed? (Parsing the...

I started working on this here: https://github.com/fthomas/refined/compare/wip/errors-as-data

Current WIP branch is https://github.com/fthomas/refined/compare/wip/errors-as-data-4

The -4 branch has been superseded by https://github.com/fthomas/refined/compare/wip/errors-as-data-5 which is pretty close to being merged to master. I'll open a PR once the last rough edges are gone. Anyhow, the...