instance/syntax traits and binary compatibility

[ceedubs]

Currently we have quite a few places where we have traits that are neither sealed nor private that house instances and syntax. For example the Option instances and the Option syntax.

Adding a new instance or method to these traits is a change that is not binary compatible. Ideally, we could freely add new instances or syntax and not have to worry about waiting until the next minor version to merge them.

Personally I know that I always get my syntax/instances via imports as opposed to mixing in traits. How much do other people value being able to mix these in instead of importing them?

[travisbrown]

How would you support à la carte vs. cats.syntax.all._ if these were objects?

I may have missed some discussion about this, but the project is young enough that it seems like it might be better to bump the minor version after every release (and save patch versions for really bad mistakes) instead of distorting code to ensure 100% binary compatibility (which we explicitly don't guarantee yet, anyway).

[ceedubs]

@travisbrown I was envisioning the traits being private[cats], which as far as I know would alleviate the binary compatibility issue (please correct me if I'm wrong).

I agree that bumping the minor version is fine for now. This is something I was aiming to address by a first 1.0 RC.

[travisbrown]

@ceedubs Oh, got it. I wouldn't be strongly opposed to making them private[cats]. (Still not sure being able to add syntax in a patch version is an especially good thing anyway, though, but I think I'm more of a syntax skeptic than most people.)

[ceedubs]

I think I'm more interested in being able to add type class instances without waiting until the next minor version. For example "oops we defined the monad for FooT[F, ?] if F has a monad, but we neglected to define the functor for FooT[F, ?] if F has a functor but not a monad". In the past it's been annoying for me to have to wait 6 months for the next version of scalaz for something like that.

EDIT: to clarify my message, I'm saying that doing the same for syntax isn't as important to me.

[ceedubs]

@travisbrown at one point on Gitter you mentioned that you've grown fond of having the instance traits exposed. However you said you'd wait until you weren't on your phone to expand upon why. Do you want to weigh in on this issue with your use-case?

[travisbrown]

@ceedubs It's partly just a vague dislike for introducing type class instances with imports, and I won't try to defend that.

The more interesting part is that being able to use the instance / syntax traits means that I can effectively "re-export" syntax, etc. for my own types—e.g. I can mix cats.syntax.SemigroupSyntax into my the companion object for my Enumerator and then anyone can use enum |+| enum without any imports at all (and this happens without muddying up the implicit scope too much).

[ceedubs]

I'm going to close this out. I've think we've pretty much settled on a convention somewhere in the middle.