I don't believe we would need the is_non_ versions because you can just invert the positive case, right? Which also means that >= just becomes "when not is_negative(val)".
My only suggestion for your latter point is that it's a far more specific use case than checking positive/negative values, and I'm just aiming for the general case here. Would you be more in favour of an is_greater_than/2 style, or is that "too close" to the > operator at that point? For what it's worth, I did some digging and already found a handful of places on GitHub that people rolled their own "is_positive" and most of them are assuming the type. Beyond that I can't check with much accuracy due to GitHub not allowing for ">" in a search. If you check for "when 0" there are also a few matches for some guard statements which also assume type. Obviously, there are false positives where the type can only be one thing, but it does show that it's not uncommon. Thanks all! On Wednesday, November 22, 2017 at 7:44:40 AM UTC-8, José Valim wrote: > > The issue with is_positive and is_negative is that they do not really > solve the problem. What if you want >= 0? Should we also add > is_non_negative and is_non_positive? Or what if you want x >= 2, which is > what you would use if you were implementing fibonacci? > > > > *José Valimwww.plataformatec.com.br > <http://www.plataformatec.com.br/>Founder and Director of R&D* > > On Wed, Nov 22, 2017 at 1:38 PM, Andrea Leopardi <[email protected] > <javascript:>> wrote: > >> is_nil/1 is harder to justify for me and I get that it could be >> implemented as "== nil". As for is_odd/1 and is_even/1, have a look at they >> implementation. They are implemented in a faster but more obscure way than >> the simple "rem() == 0" or "rem() == 1". >> >> >> Andrea Leopardi >> [email protected] <javascript:> >> >> On Wed, Nov 22, 2017 at 4:22 PM, Isaac Whitfield <[email protected] >> <javascript:>> wrote: >> >>> I'm curious what you feel about is_odd/1, is_even/1 and is_nil/1? >>> >>> On Wednesday, November 22, 2017 at 7:20:35 AM UTC-8, Tallak Tveide wrote: >>>> >>>> >>>> >>>>> Sure, but saying "we'll never fix them all, so why even try?" is not a >>>>> good argument. Saying that the solution is unit tests is true for every >>>>> behaviour; moreover people who don't know this semantic wouldn't test for >>>>> it. >>>>> >>>>> >>>>> >>>> I'm arguing that I feel this direction is not what I would expect of >>>> Elixir, being a dynamically typed language. I would not trade "bloating >>>> the >>>> Kernel module" (sorry for not finding a nicer wording, I don't mean to be >>>> harsh) for this functionality. >>>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "elixir-lang-core" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected] <javascript:>. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/elixir-lang-core/09ce8113-eb6f-41cd-aa06-9885c79098e4%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/elixir-lang-core/09ce8113-eb6f-41cd-aa06-9885c79098e4%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "elixir-lang-core" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/elixir-lang-core/CAM9Rf%2BJmDDSS3pnMkiPOthE7p6JT%3Dsq4Z__frjzQzH5KOpV8yw%40mail.gmail.com >> >> <https://groups.google.com/d/msgid/elixir-lang-core/CAM9Rf%2BJmDDSS3pnMkiPOthE7p6JT%3Dsq4Z__frjzQzH5KOpV8yw%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/0054998a-61b9-483d-8d5f-c5b52701759b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
