Consider adding some form of newtypes to cats

[LukaJCB]

We have https://github.com/alexknvl/newtypes, but we could also look at other options :)

[sir-wabbit]

Once scala/scala#6074 is merged in and there is a scalameta release with https://github.com/scalameta/paradise/pull/207 (maybe M10 already has it), that technique will be more usable. There are also some issues with IJ and newtypes with existential parameters at the moment. scala/scala#6088 could improve the performance a bit (?).

[LukaJCB]

Maybe we should wait out this: http://docs.scala-lang.org/sips/opaque-types.html

[kailuowang]

Options that I see so far.

1. depends on https://github.com/alexknvl/newtypes Update: can't use this as is unless we drop 2.10 support
2. depends on an adaption of https://github.com/estatico/scala-newtype which doesn't support type parameter as of now. @alexknvl might be able to do some experiments with it.
3. fold a newtype project (one of above) into a cats module (could be cats.kernel or a new one) that other cats modules depends.
4. wait for opaque-types, basically it means no newtype for cats 1.0

[kailuowang]

I am okay with either 3 or 4.
2 is still a question mark. but generally speaking, if cats.core has depend on something it has to be something that we have control over binary compat, otherwise Cats' bin compat promise becomes rather useless. so neither 1 or 2 should on the table.

[edmundnoble]

I prefer 3. I'm not really okay with 4 myself. I think we're going to get stuck with a lot of things we don't want to be stuck with if we wait that long.

[oscar-stripe]

I prefer 4 since we are in the midst of this currently unfolding.

Also, can we have some concrete proposals of where we want newtype in cats? For things like EitherT or OptionT or something? Can we actually make a benchmark that shows some win first? Usually one more allocation in a stack 2-deep of monads is not actually going to be a big problem.

I don't want to complicate things, nor consider dropping 2.10, if we don't have a concrete win to look at.

I added this in gitter:

the newtype macro is very new.
it would be safe IF:
1) the encoding is binary compatible from release to release. Which it may or may not be.
and
2) it leaves no runtime calls in the generated code that make visible changes to the class files.
even if that is true today, it might not be true tomorrow. I think it is a risky bet, unless you are willing to stay on a fixed version after some change comes.
in my experience, binary compatibility with scala is a big pain.

[kailuowang]

For context, the use cases for newtype in in cats that I noticed recently.

1. In Consider Reader-style instance for MonoidK of Kleisli #1928, to represent the endmorphic Kleisli
2. Several newtypes in Add Parallel type class #1837
3. SemigroupK and MonoidK as pointed out in Removing MonoidK and SemigroupK #1932
4. OptionT, EitherT as suggested above by @oscar-stripe . Although I am not sure if they are the original incentive by @edmundnoble.

[LukaJCB]

To add to those, we also have NonEmptyVector and Nested come to mind. Also those defined in newts. :)

[edmundnoble]

I think I can try for a stab at the use-cases we have in addition to the ones presented so far.

Type class disambiguation

• First and Last semigroup, as in x |+| y == x and x |+| y == y
• FirstOption, LastOption monoids, FirstEither, LastEither semigroups. Same for transformers
• Sum and Product monoids for numeric types
• Validated as a newtype over Either

Zero-overhead data types

• All monad transformers
• NonEmptyList and NonEmptyVector
• Every data type we have, all of it, which has a single-member

[kailuowang]

@LukaJCB I am curious if you still plan to do the benchmark?

[LukaJCB]

I haven't made a lot of progress yet. Tried for about an hour last weekend, but ran into some errors with JMH in combination with @alexknvl newtypes library, will have to do more research on that

[kailuowang]

Given the scope mentioned above, and the fact that the new type mechanism in Scala doesn't seem to be stable yet, also once the opaque type is out, we probably have to change it again. Now I incline to not include it in Cats 1.0 and lock it down. Users can choose their own new type lib for now. Cats internal usage of new type might be easier to manage (IRT to backward compat) if we keep the new type mechanism also internal.

[johnynek]

I agree this is premature for cats 1.0.