To be clear, those macros are used correctly within Timex, but that pattern is not safe in general, as the arguments are expanded multiple times, if the expanded arguments perform side effects, you'll have a bad time. Since those macros are meant for internal use only in Timex, I wasn't worried about it, but I wouldn't use it as a good example - it's very much macro abuse ;)
Paul On Mon, Nov 20, 2017 at 12:15 PM Isaac Whitfield <[email protected]> wrote: > Pure coincidence but whilst browsing the Timex library, they also had to > roll their own - so it can't be just me! > https://github.com/bitwalker/timex/blob/c86a96af43cb0052249a4899d988aaa4f665982b/lib/timex/macros.ex > > > On Sunday, November 19, 2017 at 4:22:01 PM UTC-8, Isaac Whitfield wrote: >> >> Hi Andrea! >> >> Thank you for your quick feedback! What you said about adding six >> functions is true, but they're very straightforward macros so it shouldn't >> be too painful. I'm not entirely sure I agree about the operators being >> more clear; people new to Elixir could simply put > 0 in a guard and just >> assume there's a type check there (even for those not new, it's easy to >> forget). Seeing is_positive/1 and is_negative/1 in code examples would >> reinforce the fact that a basic > is not sufficient. >> >> I think this use case is common enough that it warrants being in stdlib. >> Integer has is_odd/1 and is_even/1 and I would imagine that is_positive/1 >> and is_negative/1 would be used at least as much (although maybe I'm >> totally wrong :D). An even more fitting example is the macro for is_nil/1 >> when that's a single conditional in a guard and really doesn't save much. >> >> Thanks for your feedback! >> >> IW >> >> On Sunday, November 19, 2017 at 4:09:40 PM UTC-8, Andrea Leopardi wrote: >>> >>> I lean on a soft no because we’d have to introduce six new functions as >>> you said, plus is_non_negative likely as well. To me, the comparison >>> operator is more clear and if you use it many many times, than nothing >>> wrong with writing down your own macros as you mentioned :). >>> >>> On Sun, 19 Nov 2017 at 19:07, Isaac Whitfield <[email protected]> wrote: >>> >>>> Hey all! >>>> >>>> Sorry if this has been broached previously, but searching didn't show >>>> anything (either on the list or on Google). >>>> >>>> I recently realised that I write a lot of `> 0` guard clauses, combined >>>> with the fact that they're either passing `is_integer/1` or `is_float/1`. I >>>> know that it's an easy thing to write yourself but: >>>> >>>> def my_function(value) when is_integer(value) and value > 0 do >>>> # stuff >>>> end >>>> >>>> def my_function(value) when is_positive(value) do >>>> # stuff >>>> end >>>> >>>> and based on the frequency I've used it, seems like a reasonable >>>> request for stdlib inclusion. >>>> >>>> So, I would like to propose the following (and feel free to shoot me >>>> down!). Of course each call would just be a macro: >>>> >>>> Integer.is_positive/1 - is_integer(val) and val > 0 >>>> Integer.is_negative/1 - is_integer(val) and val < 0 >>>> Float.is_positive/1 - is_float(val) and val > 0 >>>> Float.is_negative/1 - is_float(val) and val < 0 >>>> Kernel.is_positive/1 - is_number(val) and val > 0 >>>> Kernel.is_negative/1 - is_number(val) and val < 0 >>>> >>>> And coincidentally, I'm assuming that it's better to perform the type >>>> check first, I guess I'd appreciate if someone could confirm that? Also >>>> goes without saying that I'd be happy to impl this if we decide to adopt. >>>> >>>> Thanks for your consideration! >>>> >>>> IW >>>> >>>> -- >>>> 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/1d9f2250-9783-4af8-b2bb-9c0379f3b122%40googlegroups.com >>>> <https://groups.google.com/d/msgid/elixir-lang-core/1d9f2250-9783-4af8-b2bb-9c0379f3b122%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> -- >>> >>> Andrea Leopardi >>> [email protected] >>> >> -- > 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/5cad86c6-4e89-485b-9db9-6a4140c13a63%40googlegroups.com > <https://groups.google.com/d/msgid/elixir-lang-core/5cad86c6-4e89-485b-9db9-6a4140c13a63%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/CAK%3D%2B-TtEJGFKyiNRoji7dELEuSZ6XqAQSsdka-SgOgQ2s8ae_Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
