#suggestion Infix operators grouping and "not match" about rfcs HOT 5 CLOSED

Your point is right: I was thinking in terms of good ol' mathematical plus and minuses, when one could actually have the .add method on their class do a multiplication and the .mul method do an addition, making my argument pointless.
I wasn't thinking about the fact that the infix operators can have different meanings depending on their uses in the user code, these different meanings making any grouping irrelevant.

Thank you for pointing me this out!

from rfcs.

@EpicEric your point...

Even in our regular math system, they are not the same thing. (a + b + d) - c could have rounding errors with big floats and give a different result than ((a + b) - c) + d, due to an intrinsic limitation of numerical representations in CPUs. Exhibit B.

Is an interesting one. If you are up for it, I think it would be interesting to add the general discussion to the operator precedence section of the tutorial. Would you be up for PRing that?

from rfcs.

I have some points against your first suggestion, which I will express below. As for your second suggestion, it makes perfect sense to me.

TL;DR: There are several cases where infix operators grouping can lead to bugs or confusion.

Grouping different infix operators would implicitly assume that they have the same order of precedence. This would create some arbitration as to whether operators have the same precedence or not, and:

The problem with this is that the programmer has to remember the order and people aren’t very good at things like that. Most people will remember to do multiplication before addition, but what about left bit shifting versus bitwise and? Sometimes people misremember (or guess wrong) and that leads to bugs. Worse, those bugs are often very hard to spot.

This also applies to "+" and "-", which may not have the same precedence to another person in another culture, or even with a different math system. Say that I want to create a module that uses these operators, where they aren't directly reversible operations (let's say, "OR" and "NOR" on U32 instead of booleans, respectively). This would be a case where ((a + b) - c) + d and (a + b + d) - c mean two different things, and infix operator grouping would silently cause bugs. Exhibit A.

(Note that this issue doesn't happen when there's only one type of infix operator, because the structure of the code itself already implies left-to-right ordering, and an operator cannot have a different precedence than itself.)

Even in our regular math system, they are not the same thing. (a + b + d) - c could have rounding errors with big floats and give a different result than ((a + b) - c) + d, due to an intrinsic limitation of numerical representations in CPUs. Exhibit B.

For these reasons, I agree with the language's design decision to keep any kind of operator precedence out of the syntax, for the sake of avoiding potentially unmaintainable code.

from rfcs.

Please split these into two different issues as they are two different issues. Also please note, that these are issues which means you would be looking for conversation and possibly someone to write an RFC for either issue. Nothing would be done one way or another without an actual RFC.

from rfcs.

Opened a new issue, I guess this issue can be closed

from rfcs.