'course it could, multiple languages already do that e.g. Rust (https://play.rust-lang.org/?gist=530fa94d3f451e896ac0d3ddeaf...), Haskell (https://repl.it/repls/FrozenBlondUmbrellabird), Swift (https://repl.it/repls/LuckyNaiveBream)
Needing to use +. to add two floats seems odd to me as well, and I believe this is what OP was pointing out. I would agree with you that adding and int to a float should require conversion of one of the arguments, but I see no need for a separate + operator for floats and ints.
Yes, what I was trying to express is that in a typed language with many types, choosing a few types and using operators to signify what you are doing is an odd choice, especially if you implement it for some types but not others. I understand the want of the language designers to protect people from these mistakes, I just think they chose an oddly inconsistent way of of doing so. The logical conclusion of different operators for different types is many more operators than shown here, so that leaves the language with these special cases. Special cases cause confusion.
Sadly, it is not associative (i.e. (a+b)+c != a+(b+c))
Imagine a being a large number, and b and c being so small that adding each single one to a will result in a, but adding their sum will result in just the smallest increment over a.
It's more like doing calculations on scientific notation, where there are special rules for how to keep the right number of significant figures/precision after operations. Like scientific notation, you would probably convert to one form or another (even if in your head) before doing the operation, and keep note of the possible loss of precision.
This is exactly the reason why adding floats to ints is something that people think should require an explicit conversion, so it's more obvious that's a point that may introduce loss of accuracy.
1: https://stackoverflow.com/questions/24442725/is-floating-poi...
2: https://www.cs.umd.edu/class/sum2003/cmsc311/Notes/BinMath/a...
Now that you mention, there was this fascinating denial-of-service vulnerability in PHP which is (kind of) related... https://news.ycombinator.com/item?id=2066352 http://www.exploringbinary.com/why-volatile-fixes-the-2-2250...
EDIT: To expand on this: The following code is valid, and may print "weird":
double x = f();
double y = x;
if(x != 0 && y == 0) {
printf("weird\n");
}
That's interesting, as being forced to use the same operator for addition and for concatenation (and what's more with the result of mixed types if allowed often dependent on the order of the parameters) has always seemed extremely inelegant to me.
Addition and concatenation are not the same thing. Why they should share a symbol when they don't share some properties integral to their nature (it's non-commutative) is beyond me, and I think it's caused a lot of bugs that didn't need to happen.
Not allowing the addition of floats and ints together is less of a fundamental issue, but it also helps quite a few problems. Al alternative solution, if you didn't want to reply on implicit coercion would be to explicitly convert one operand to the appropriate type so they match.
Or you can go whole hog and provide an entirely separate set of operators for different types, like Perl did (string concatenation is '.', and equivalents comparitors are eq,ne,gt,lt,ge,le). That works well in Perl's case, but that's mostly because for Scalars Perl really just wants to know whether you are treating it as a number or a string, so there's only two types to account for.