refined
refined copied to clipboard
fthomas
Reduce API surface
In #382 I expressed concerns about adding a variant of the validate method that doesn't require a full refined type, because I feel the current API surface is already quite large and the library provides sometimes more than one way to do things (especially with the addition of companions for refined types, see #369). It would be nice if we could reduce the API surface and make it more approachable.
This issue is about collecting weak spots in the API and things we can improve.
Would it be an option to drop support for @@ style refinement types? Supporting it and Refined doubles the API surface area. And my impression is that everyone is using Refined now? Or is there an advantage to using @@ in some instances?
Early versions of refined used @@ exclusively because I thought using a well established tag type would be beneficial and that the subtyping relation T <: T @@ P is a suitable property for refinement types. Later I found out that the encoding of @@ does not work very well with type aliases (#21) which is a big disadvantage and introduced Refined then. The only advantage of @@ is that it has a smaller runtime overhead compared to Refined (see RefineJavapSpec.scala).
So :+1: for dropping support for @@ or at least dropping special syntax for it like refineMT and refineT.
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 in the refined-scalaz.