Generalizing number types seems harder than it should be

[sangamon]

@SJohn

So, Scala’s nominal nature is what creates this limitation?

Well, yes, if you want to call it a limitation. To me it looks more like a deliberate design decision in the first place. (But I may actually be wrong.)

Here’s a somewhat related previous discussion:

A little disappointed with unions in Scala

I’m glad that Scala 3 introduced unions (and intersections), but I’ve just discovered there’s no narrowing and no support for structural typing. The following would work both in Python (pyright / mypy) and TypeScript: def f1(x: Int | String) = x match case _: String => "str" case i => String(i + 3) // no narrowing def f2(x: Int | String) = if x.isInstanceOf[String] then "str" else String(x + 3) // no narrowing class A(val x: Int) class B(val x: Int) def f3(x: A | B): I…

@SJohn

Also, I’m curious why Scala didn’t implement a common base interface Number for all of these primitives, isn’t that what Java did?

Java has an abstract class Number for the boxed primitive wrappers - I wouldn’t call this a great design. And I do recall that even back in the days when I was doing full OO Java, I’d prefer using Comparator (a poor man’s “type class”) over Comparable for various reasons. IOW, I don’t think having Numeric implemented as a type class must necessarily be a big surprise for anybody coming to Scala from the Java side - it wasn’t for me.