Ok, but then they should explain this particular case better. The RHS can be figured out just by choosing the overloaded operators.
In C++ terms, if you have int& operator+(const int&x, const int& y) then (1 + 1) is not ambiguous and can be selected fast. Same for unary minus etc.
The Swift devs should then blog about this example and explain step by step what is going on. If the literal "1" can be both an int and a float, that of course would be insane. Is that what you meant by "polymorphic literals"?
That is outrageous. It also cannot be blamed on Hindley Milner. While HM in theory has exponential worst case time, the constructs to trigger it for OCaml and Standard ML are far more complex, carefully constructed and never occur in practice.
OCaml does have +. for floats to make type checking easier, but Standard ML does not. Also, if Swift has operator overloading, why isn't it instantly clear that the RHS is an int, which can be assigned to a double?
This just looks like a performance bug in the type checker, and nothing that is inherent to HM.
In C++ terms, if you have int& operator+(const int&x, const int& y) then (1 + 1) is not ambiguous and can be selected fast. Same for unary minus etc.
The Swift devs should then blog about this example and explain step by step what is going on. If the literal "1" can be both an int and a float, that of course would be insane. Is that what you meant by "polymorphic literals"?