I’m working on a project right now that makes heavy, heavy use of Decimal. I just hit bug today where >= was used instead of Decimal.compare/2 and it’s not the first time I’ve seen this happen.
Additionally, Decimal has some nice convenience methods (as Java-esque as they are) such as eq?/2 and gt?/2. This is nicer than having to drop into compare/2.
It seems like protocols could totally make operator overloading a thing. I would obviously really like to just be able to do %Decimal{} + %Decimal{} and have it work like Decimal.add/2. And, coming from a Ruby background, I’m, used to overloading a lot.
These are just functions, yes? I can pipe with Kernel.+/2 and Kernel.==/2.
Having said all that, this seems quite deliberate and I feel like with as much as I have read I would have come across the answer but… I don’t know. And either my Googling skills are poor or I’m asking the wrong question.
Why doesn’t Elixir support standard operator overloading?
defmodule MyDecimal do
defmacro __using__(_) do
quote do
import Kernel, except: [+: 2, -: 2, ...]
def left + right do
Decimal.add(left, right)
end
def left - right do
Decimal.sub(left, right)
end
# ...
end
end
end
For me, the lack of operator overloading is part of what makes Elixir a good dynamic language as it still cares about types. It’s also part of (all of?) what is enabling the possibility of strong arrows (if we get some static typing). If you looked at a language like OCaml it goes even further. + only adds ints, you need to use +. to add floats! And you must explicitly cast one side if you want to add a float to and int.
I don’t know if this is the exact reason Elixir doesn’t overload, though.
I think the reason is not to make unreadable code, the example you provided shows clearly how someone can get lost when he will want to use + with non decimal values.
In this case matching or a guard would be a better solution if that is possible, I didn’t work with operators before in elixir so I have no idea about the potential limitations.
That’s an interesting example. You could contextually overload (almost like a Ruby refinement) in the current module.
With that said, I can see the argument for arithmetic operators. I almost wish I hadn’t included it because what was lost was not that potential convenience.
The pain point isn’t really arithmetic. Decimal.add/2 will chuck an ArithmeticError if you try and just use +. So I might gripe, but I can easily fix.
The real problem comes with equality operators. They won’t chuck an exception. They’ll often just be flat out wrong. (Well, “wrong” in terms of what I intended when comparing structs, because it compares just as it would a map because… it’s a map.) So instead of getting a “you can’t do this” I get something that can fail in subtle ways.
Awesome. A buddy of mine actually just pointed me to this commit.
It is indeed a conscious decision related to readability:
Note the Elixir community generally discourages custom operators. They can be hard to read and even more to understand, as they don’t have a descriptive name like functions do. That said, some specific cases or custom domain specific languages (DSLs) may justify these practices.
I guess in that case, just like structs don’t work by default with the Access behaviour, it would sure be nice if they blew up on equality operators if they hadn’t implemented compare/2 although I suspect there are issues with that.
You could replace == operator with a custom one that would make the necessary checks, at compile-time/runtime overhead if that is critical for business.
CompareChain might help with some of your use cases (shameless plug: I’m the author). I had similar headaches working with DateTime structs. It’s easier to read code like:
left <= right vs
DateTime.compare(left, right) != :gt.
CompareChain is a sort of middle ground where you can write this:
import CompareChain
a = Decimal.new(1, 42, 0)
b = Decimal.new(1, 42, -1)
compare?(a >= b, Decimal)
Sorry I’m a bit lost in your wording re: unreadable code but I’m talking more how many languages overload + to work with several data types, like: 1 + 1, "Hello" + "!", and [1, 2, 3] + [4] whereas Elixir has its own operators. But of course:
I always forget about this when thinking/talking about this and ya, that always gets me as I wish there were strict “math” versions. So, ya, it’s best to use guards and pattern matching when working with equality.
Note that is says “generally” I think if you have a lot of often-edited modules in your business domain that deal purely with decimals, it would be totally fine to write a macro like my example. You can also override per function scope too! Just don’t do it project-wide. There are very good libraries out there that overload these operators, like Image (see the Math module] and Pathex (allows you to use / as a path separator). But if it’s for some simple convenience for a module or two that don’t get changed much, I personally wouldn’t bother. It just makes it confusing later on.
I come from a Ruby background so… I use and abuse overloading, lol. I’m okay with a decision one way or another. At least it isn’t Java’s “you can’t overload but we selectively have one overload exception for concatenating strings.”
I also come from a Ruby background and was all about Ruby metaprogramming (until I wasn’t). I’ve grown to much prefer the Elixir way of life. I too was perturbed by Decimal and DateTime the first time I saw them but I now prefer it! Especially Time#+ in Ruby… like, why does it allow Time.new("2023-10-20 00:00:00") + 1. 1 what!?? This isn’t even Rails cheekiness, this is stdlib! Who LGTM’d that proposal???
As a full time Elixir dev now, I would say that overall I prefer Elixir. Toward the end of my Ruby career I was writing more functionally anyway, so a lot of dependency injection and as little implicit state as possible in classes. I was actually writing many, many function modules by the end. I still find working with dates and times in Elixir to be extremely cumbersome compared to Ruby.
Things like date + 1.days are amazing. The DSLs around dates were just cool. I know there are tradeoffs and such, but sometimes in the Elixir world there’s an immediate mentality that “clarity” is objective. It’s really not. Someone who is not a programmer can read that and grok it.
And I just don’t love Decimal as it is. I get why a line was drawn in the sand, but working with a value that is clearly and conceptually a number and not being able to arithmetic operators on it is—call it what you want, a trade off or a wart—to me it makes even less sense in a language that doesn’t have a concept of primitives like Java or Objective-C.
The problem is, of course, there isn’t a way I can think of to reasonably restrict overloading to just that. (I’ve always found operators to be weird anyway. In these higher level languages, they’re just functions with a special form.)
Anyway, just griping. There’s no such thing as the perfect language for my tastes! (Or anyone else’s, lol.)
Thanks for all this info. I really appreciate the sources. I’ll read through this in depth later.
I mostly want to reiterate a point made earlier in this thread. Overloading is discouraged „generally“ or in other words without additional context. E.g. you can look at Nx and see it overloading operators for tensor based mathematical operations, but that‘s fine because the context for that is scoped to defn functions.
Similar approaches can be done in various forms using macros.
I also fully acknowledge that decimals are numbers as well, but that just shows very explicitly that decimals are not a primitive datatype on the beam, but a user defined type based on maps. Same thing applies to all the datetime stuff.
Used to think so myself (had 6.5y with Rails before I moved to Elixir) but honestly, my day is not ruined for having to write this instead:
NaiveDateTime.add(date, 2, :day)
Also don’t forget that time is very finicky, we still have leap seconds and summer/winter time jumps. There are situations, just in the right two dates of the year, where adding a few hours to a datetime will lead to ambiguous times, e.g. check this out: Timex.AmbiguousDateTime — timex v3.7.11
Having arithmetic operators for something that can jump back or forth beneath your feet I would find suboptimal and unpredictable. I’d prefer patter-matching on the result of a datetime operation, including the ambiguous results.
We don’t have the concept of primitives, as in those languages, but integer and float are built-in types and decimal is a custom one. So there is a clear demarcation here. In any case, if I could, I would support decimal + integer, but we can’t do it today without making it slower for all cases and without breaking guard semantics. The shortest way around this is to have decimal as a native VM type.
Other than that, I am very glad to not have date + 1.days, because there isn’t anything arithmetic about it. For example, it is not guaranteed that (date + duration) - duration == date. I do like 1.days though, as a mechanism to express durations, but I would be 90% as a happy if we had Date.shift(date, months: 1, days: 10) in Elixir (PRs are welcome, I consider this to be the last calendar feature missing in Elixir).
Finally, the hope is that once we have the type system, we will warn if you give a struct to any >, >=, <, and <=. It is pretty much a language pitfall that I hope we can address more reliably.
I think if you have a lot of often-edited modules in your business domain that deal purely with decimals, it would be totally fine to write a macro like my example. You can also override per function scope too! Just don’t do it project-wide. There are very good libraries out there that overload these operators, like 
