typelevel / typelevel/cats

Ordering of ensure / ensureOr arguments in MonadError

Open
#2,875 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Binary Breaking Source Breaking
Dominant language
Scala
Stars
5.5k
Forks
1.2k
Avg merge
2d 10h
Merged PRs (30d)
5

Description

Apologies if this has already been raised; I couldn't find any related Issues / PRs.

I'm just wondering what the reasoning is for the ordering of the arguments of MonadError#ensure and MonadError#ensureOr.

I think typical usage of them leads to code that reads confusingly e.g.

case object CustomerUnderage extends Exception
def isCustomerOfLegalAge(customer: Customer): Boolean = ???

// F has MonadError type class
val customer: F[Customer] = ???

// current API - reads confusingly i.e. ensure customer is underage ?!
customer.ensure(CustomerUnderage)(isCustomerOfLegalAge)

Instead, what are peoples' thoughts on something like:

// proposed API
customer.ensure(isCustomerOfLegalAge)(onError = CustomerUnderage)

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reading the MonadError#ensure and MonadError#ensureOr entry points and compare their current argument ordering with the proposed calls in this issue. Done means reaching a maintainer-backed decision on whether the API should change; the issue does not identify implementation files or tests.

Written by the indexing model from the issue text.

Assessment

Tech stack
scala
Domain
backend-api-design
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.