Операции везде работают по разному и выделять их в интерфейсы - так себе идея. Решать это можно тайп-классами, но у них есть проблема с тем, что к одному типу операции прибиты гвоздями и будут беды, когда не совсем  однозначное прочтение операторов. В Kmath это решается разделением операций и значений, то есть добавляются экстеншены в зависимости от того, где используются элементы. На самом деле хаскель тут не спасает, потому что байндинги для тайп-классов все равно надо писать.

ах да, я забыл, что в жаве/котлине НЕТ ТАЙПКЛАССОВ

Операции везде работают по разному и выделять их в интерфейсы - так себе идея. Решать это можно тайп-классами, но у них есть проблема с тем, что к одному типу операции прибиты гвоздями и будут беды, когда не совсем  однозначное прочтение операторов. В Kmath это решается разделением операций и значений, то есть добавляются экстеншены в зависимости от того, где используются элементы. На самом деле хаскель тут не спасает, потому что байндинги для тайп-классов все равно надо писать.

Тайпкласс тут не поможет. Потому что операция неоднозначная. В Kmath как раз эмулируются тайп-классы, но с явныой передачей контекста. Это решает проблему неоднозначности

А, ну так в свифте с этим дела попроще.

> Потому что операция неоднозначная
Какая операция неоднозначна?

так я не против написать тайпкласс для своего нового типа чиселок

Там вопрос не в этом, а в том, что такое Int + Double

В смысле? Проблем собственно в том, что Int + Double  не равно Double + Int если операция диспатчится по первому аргументу

В смысле? Проблем собственно в том, что Int + Double  не равно Double + Int если операция диспатчится по первому аргументу

а с чего бы был Int + Double?

Ну типа, если у меня

interface Plusable<A> {
  fun plus(a: A, b: A): A
}

и есть инстанс для инта и дабла, я с одной этой фигней их сложить не смогу