In type theory, a refinement type[1][2][3] is a type endowed with a predicate which is assumed to hold for any element of the refined type. Refinement types can express preconditions when used as function arguments or postconditions when used as return types: for instance, the type of a function which accepts natural numbers and returns natural numbers greater than 5 may be written as f: \mathbb{N} \rarr {n: \mathbb{N} | n > 5}. Refinement types are thus related to behavioral subtyping.

I think that's completely consistent with the notion of refinement in the SLS.

Ok, I think I understand that this is true for @@. But there is also the case class Refined[T, P](t: T) value class that I added for better type inference when using an alias like type PositiveInt = Int Refined Positive. Since Refined[T, P] is not a subtype of Tit is definitely not a refinement in the SLS sense

Like I said, I think that SLS refinements are refinements in the sense described in the wikipedia article (which is a good short characterization IMO).

If you have some additional types which are not SLS refinements but which also mesh with the spirit of the idea of "refinement type" (ie. by encoding refinements as non-SLS refinements) then that seems fine too.

If you really wanted to be picky you might say that Refined is an encoding of a refinement type whereas an SLS refinement is an actual refinement type.