.toOptionT has inconsistent semantics.

[stewSquared]

This lifts something into an OptionT, so we should instead just use built-in lift. Or use constructors
The built-in .toListT converts an OptionT to a ListT, so .toListT.toOptionT.toListT.toOptionT doesn't result in the same initial type, but keeps adding layers of nesting.

Also, this just adds to a growing list of magic extension/methods and implicits.

[jodersky]

kill it!

Also, are we using github issues to track things? That's cool!

[stewSquared]

are we using github issues to track things?

I've always done so for core stuff, against company instructions to use JIRA org-wide. It's too much work to go to the SCALA JIRA board, and I hate not being able to cross reference PRs and Issues, which I do quite liberally.

Right now, the set of issues in Jira and Scala only overlap partially. Perhaps we should use GitHub projects, so we can have a board that tracks these issues across repos.

[vuspenskiy]

What for me, I hate to write the boilerplate which those methods replaced, especially when some "built-in" methods should work but because actually Scala's type-checker gives up too fast you ending up writing half-line of the type annotations.

PS: you may mention Jira issues' keys in the commit message and cross-reference tickets and PRs from Jira.

[vuspenskiy]

Unfortunately, our previous convo about that with examples probably was on the driver-api repo PR which is removed now.

[stewSquared]

@vuspenskiy Yes, I do remember our previous convo (in slack, which probably reference gitHub). But there has to be a better way. At the very least, we should rename this to .liftToOptionT

Check out the cats documentation, for example: https://typelevel.org/cats/datatypes/optiont.html

[stewSquared]

re: JIRA

My statements were a little strong. Yes, we can cross-reference, but it's much easier in GitHub. And since we're now using Pivotal, some of the benefit of having a Scala board is lost.

[vuspenskiy]

@stewSquared I still hope that the consumer FE will return back to the mother-tracker :)

Although we definitely can consider Github issues for some stuff, but I'd love to check with product people (e.g., @ssoi) because I think they should have visibility into what we're doing and be able to plan too, at least for services' repos, and for libs we can add links to GH to relevant tickets in Jira.

[vuspenskiy]

I'd love if idiom brackets implementations for Scala (e.g., https://github.com/aztek/scala-workflow) would lift expressions to the most nested level in the context automatically (what they can't do now), or maybe if we have our own master-monad (like Effectful one, or Computation in PDS UI) it could have concise constructors for all the different types and those conversations would go?