I believe there is a similar case for including standard Decimal handling in Elixir just as Date and Time have been standardized as a core part of the language.
Your thoughts?
While it wasn’t difficult to pull in the dependency, I agree that I expected it to be part of the standard lib.
It’s currently being discussed in the core team if we should add the Decimal library to the elixir standard library. It may or may not happen.
The main reason the calendar types were added to core elixir was to have a common set of data structure all the libraries could use and work on. For decimal types we don’t have this need since afaik there is only one decimal library in the ecosystem.
If you want Decimal added to the standard library you need to argue what the benefits would be.
3 Likes
But you have just pointed it out Eric …
There is only one Decimal Library
— If you use Ecto, you automatically pick up this dependency.
Also, HEX places Decimal in the Top 6 libraries …
Having decimal in the language just seems natural.
Unless you know of any Erlang plans to support it as a generic type, I think it’s a good fit for the type of stuff Elixir should offer by default.
That’s not really an argument, except that it’s popular. The webserver cowboy and dependencies are even more popular, should they also be included in core elixir?
Every extra module in core elixir puts extra burden on the elixir core team. That means less new features and less bug fixes for the existing code in the standard library. The more code the community can take care of the better and with the dependency handling in mix and package management in hex it’s not that much extra work to use a dependency.
2 Likes
We need to have a long timeframe in mind here. Though I agree that a Decimal built-in would be useful, it does not add much value to add it right now. As there is only one Decimal implementation in use, we should continue using that. At the point where there suddenly for some reason exists alternative Decimal implementations, that would be a much better time to discuss adding it to stdlib, as the problems/design challenges involved would be much better known.
So my vote goes to postponing this at least a few years in time…
I guess it would make only sense to have it part of the core if it was a simple type, that could use +/-/* operators. If we kept the need to use Decimal.add and friends , this can very well be a separate lib.
4 Likes
I agree with this sentiment.
Unfortunately, as +, -, etc are not expected to be overridden because they would stop working in guard clauses (There’s some things we just cannot do in guard clauses right now), I don’t think this will happen anytime soon.
FWIW, I have been experimenting with an alternative approach to the Decimal Library.
IMHO, the underlying data structure is not a “solved” problem. Until there is consensus on the underlying data structure, I think putting it in Core is not reasonable.
