This issue began with I posted a question to cats gitter - is there support for conversion of Boolean to Option values, like the option[A](a: A) method in Scalaz.

Two other example where people have/want-to enrich standard lib classes with extra behavior:

• Issue Add cata to syntax.option #749
• https://github.com/non/cats/blob/master/core/src/main/scala/cats/syntax/option.scala#L26

The scalaz.syntax.std package has a bunch more that could be supported if/when useful or requested, egs:

• BooleanOps
• ListOps

Opinion seemed to run against adding such "conveniences" into cats core in general, eg @travisbrown response. But in following discussion there seemed to be agreement they have value and for putting them somewhere in a new module or project (working title extra-syntax).

Our immediate goals are to answer:

1. What should the scope/charter of extra-syntax be? I'd say the primary goal is Improvement/enrichment of the standard library classes, with secondary goal increase familiarity & portability for Scalaz programmers.

   The principle I stumble to articulate though is, when does code go into extra-syntax vs cats syntax?

   Proposal:

   • conversions of std types to cats datatypes (eg Option => Xor) go into cats core
   • methods that enable/support using cats typeclasses go into cats core

   Anything else goes to extra, such as conversions between std types, or extra methods like option.cata.

   Or is the distinction more about barrier-to-entry/level-of-consensus? If everyone agrees its central, it can go to cats core, if there's doubt its goes to extras? Not too keen on this, I'd prefer a more objective criteria ideally..

2. Should it be a new project or a new module? My feeling at present is that it'll prove to be pretty small, only the most valuable tip of scalaz.syntax.std will be requested, and so a module with cats is preferable to another project. Not a strongly held position however.