Neater syntax

[lJoublanc]

Is there some technical reason for the Impl object inside the newtype, rather than making the methods part of the newtype object itself?

It just seems to make everything clunkier ... i.e. writing MyInt.Impl(1) rather than just MyInt(1), like a value class? Perhaps there is some other way of doing this, but it's not obvious to me.

Also, would it make sense to add an unapply to allow pattern matches, again to work like a value class?

Great lib btw. The linked articles were also an compelling read for me!

[neko-kai]

Try out https://github.com/estatico/scala-newtype/blob/master/README.md which is a similar, but much more fleshed out lib

[lJoublanc]

Also, since the @newtype annotation gives your type a distinct type at compile-time, primitives will naturally box as they do when they are applied in any generic context.

@kaishh This is one of the primary reasons why I chose to go with this lib; it allows you to avoid boxing. I work with Array[Double]s a lot, and I want to change Double to it's own type, hence this won't really work for me.

[neko-kai]

@lJoublanc AFAIK NewSubType encoding there is at least equivalent to one in this library. You may want to look at https://github.com/typelevel/machinist for something that definitely avoids boxing (via macros)