> 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)".
Right. Although I find "is_integer(x) and x >= 0" much clearer than "not Integer.is_negative(x)". The second is even longer. *José Valimwww.plataformatec.com.br <http://www.plataformatec.com.br/>Founder and Director of R&D* On Wed, Nov 22, 2017 at 6:53 PM, Isaac Whitfield <[email protected]> wrote: > 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]> >> 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] >>> >>> On Wed, Nov 22, 2017 at 4:22 PM, Isaac Whitfield <[email protected]> >>> 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]. >>>> To view this discussion on the web visit https://groups.google.com/d/ms >>>> gid/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]. >>> To view this discussion on the web visit https://groups.google.com/d/ms >>> gid/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 > <https://groups.google.com/d/msgid/elixir-lang-core/0054998a-61b9-483d-8d5f-c5b52701759b%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]. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4%2Bb3rNi1PvP-KyJA_yLGQmDAg4bLZ-_FQ6NYodkPeh%3DAQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
