[2.13.0-M4] Keep the override on the symbolic operator

[MasseGuillaume]

Let's say I implement a Map in 2.12. I need to override def - (key: K): C. If I bump the Scala version to 2.13, I now need to override the alphanumeric method remove(key: K): C.

https://github.com/scala/scala/blob/a0026305125dcc814097b1fbb798fe925ca9f81f/src/library/scala/collection/immutable/Map.scala#L59-L62

currently:

def remove(key: K): C
@`inline` final def - (key: K): C = remove(key)

I propose we keep the symbolic operator non-final for compatibility:

@`inline` final def remove(key: K): C = this - key
def - (key: K): C

[sjrd]

Drop them. It's only relevant for custom collections, and compatibility for custom collections are DOA.

Also, the override wouldn't really be compatible, since it would fail to implement/override remove accordingly anyway. So a hard error is required, not just a deprecation.

[MasseGuillaume]

Also, the override wouldn't really be compatible, since it would fail to implement/override remove accordingly anyway. So a hard error is required, not just a deprecation.

I don't understand this point. Can you elaborate more?

[sjrd]

If a user calls remove, they won't use the implementation in the overridden --. So overriding -- breaks the contract that remove and -- do the same thing. One would need to also override remove to protect the contract, but if they do that, overriding -- is pointless. So there is no reasonable scenario where overriding -- is correct.

[julienrf]

@sjrd The idea in this issue is to simplify the migration work and to make it easier to implement custom collections that cross-compile.

In 2.12, when you implemented a Map, you had to implement the + and - operators.

In 2.13, you now have to implement updated and remove (+ and - are final aliases to these operations).

By changing the collections in 2.13 to define alphabetic operations as aliases to the symbolic operators (instead of the other way around, like the current situation), we would simplify the migration work for custom collections implementers because they would have to implement + and -, as before.

[sjrd]

You are not helping my migration if you allow my code to compile with incorrect behavior. Keep my behavior intact if you can. If you can't, please prevent my code from compiling.

[julienrf]

What would become incorrect?

[MasseGuillaume]

@sjrd remove is final in my proposal, how would you override it?

I'm only pointing out that in < 2.13, there were only symbolic operators (+). As a custom collection implementer, this is what you need to implement. In >= 2.13, you need to implement the non-symbolic operator (remove), and you need to provide a cross-compatibility layer.

For example, we want to cross compile a mutable.Builder for scala-stm:

1. Implement the builder with addOne such that it can compile in >= 2.13 step 1
2. Add a template to refine thi implementation for < 2.13 step 2
3. Implement the template with an empty stub for >= 2.13 step 3
4. Implement the template with + in < 2.13 step 4, step 5

[sjrd]

Ah, my mistake. I didn't see that you suggested remove to be final instead. Yes, that would indeed be fine. If you do that you also need to do it with append and all the other methods that have switched from a symbolic name to an alphanumeric-plus-symbolic-alias name.

[Jasper-M]

Disregarding compatibility, I have to say I find it a lot cleaner to have the symbolic operators be final aliases, and the alphabetic methods be overridable.