Map.delete and pure/Map.delete have inconsistent semantics

[crusso]

The former traps deleting an absent key, the latter does not.

I suggest

add/remove trapping
put/delete non-trapping

[rvanasa]

What about add() : Bool and remove() : Bool (non-trapping)? This would make is so that the developer must either explicitly ignore the expression or provide some sort of error handling logic. We could also include addChecked() : () and removeChecked() : () (trapping), although I think it would be better to discourage trapping in favor of giving the developer a way to handle the error in context.

Another variation is add() : () and remove() : () (non-trapping) with addSafe() : Bool and removeSafe() : Bool (also non-trapping), along with the trapping functions if we want to include those.

The motivation is for addAll(), removeAll(), and retainAll() to correspond in a more intuitive way to union(), diff(), and intersect().

It might be good to keep "add" and "remove" (or I suppose "put" and "delete") in both of the names if possible, since otherwise it could be confusing to new developers who might mix up which functions are paired with each other.

[crusso]

Boolean add and remove would solve the problem but might lead to awkward code with all those ignores in the common case. And would 'addAll' etc return a bool and if so, with what semantics ?

Maybe just non-trapping add/remove
with boolean put/delete?

I was also wondering if we could use

Union/intersection/difference (creating a new map)
And
Unite/intersect/diff for inplace update (in the imperative API)

Let's talk tomorrow...

[rvanasa]

Maybe just non-trapping add/remove with boolean put/delete?

I'd be ok with this, although a remaining concern is that it might be confusing to remember which ones return a boolean.

Unite/intersect/diff for inplace update (in the imperative API)

In this case, we might want to rename the functions sort() -> sorted() and sortInPlace() -> sort(). Otherwise, I suppose unionInPlace(), intersectInPlace(), and diffInPlace() (or with the words fully spelled out) could also work as an admittedly verbose naming convention.

Overall, I've been choosing names based on consistency first, clarity second, and conciseness third as an explanation for thinking *InPlace() could make sense despite being verbose. This also comes from the Python ecosystem where data structures (primarily dataframes) have in-place operations such as df.sort(..., inplace=True).

[crusso]

The other thing that strikes me is that the Boolean ones are truly awkward in the functional api since you need to return a new map and a Boolean. Wouldn't be so bad if we had subtyping on tuples (you could ignore the second value) but we don't..
Let's do something else in the meantime and discuss tomorrow