# The problems with numbers in Elm

**URL:** <https://discourse.elm-lang.org/t/the-problems-with-numbers-in-elm/5680>\
**Category:** Request Feedback\
**Created:** [May 1, 2020, 12:29am UTC](https://discourse.elm-lang.org/t/the-problems-with-numbers-in-elm/5680 "2020-05-01T00:29:25Z")\
**Posts on this page:** 1\
**Showing post:** 10

<div class="post-metadata">

**Author:** ![jfmengels](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/jfmengels/32/3124_2.png) [@jfmengels](https://discourse.elm-lang.org/u/jfmengels)\
**Post date:** [May 1, 2020, 9:12am UTC](https://discourse.elm-lang.org/t/the-problems-with-numbers-in-elm/5680/10 "2020-05-01T09:12:56Z")

</div>

I agree with @Lucas_Payr. I think that having a native solution would be imperfect in a lot of situations, like if you wanted to model numbers that fulfill other conditions (even or odd, inside a (in)finite set of numbers like {1, 2, 3, 5, 8, 11, …}).

I think that this check is best done in custom code, therefore in a custom opaque type.

You’ll have to deal with a lot of safeguards (functions that return `Maybe`s in case your value doesn’t match the conditions), but I think that that can be simplified when something is easily detectable through static analysis, as I described in [safe unsafe operations in Elm](https://discourse.elm-lang.org/t/safe-unsafe-operations-in-elm/5659).

---

_[View the full topic](https://discourse.elm-lang.org/t/the-problems-with-numbers-in-elm/5680)._