IIRC, macros do not allow to abstract both the pattern match and the guard within the same expression. For example, the Elixir codebase contains a helper function that abstracts the pattern match, the guard and the "read" function for dates and times separately. Here is the helper function https://github.com/elixir-lang/elixir/blob/master/lib/elixir/lib/calendar/iso.ex#L39-L70; and here is an example of its usage https://github.com/elixir-lang/elixir/blob/master/lib/elixir/lib/calendar/datetime.ex#L522-L531.
Besides, as described by José Valim in here <https://github.com/elixir-lang/elixir/blob/master/lib/elixir/lib/calendar/iso.ex#L39-L70>, internal guards would allow to write macros like: def my_fun(my_macro()) which would be expanded to: def my_fun(my_var when my_var in [:foo, :bar]) and rewritten by the Elixir compiler to: def my_fun(my_var) when my_var in [:foo, :bar] However, I'm not sure how common are those use cases 🤔. On Monday, September 24, 2018 at 8:22:07 PM UTC+2, Allen Madsen wrote: > > If the goal were primarily macro usage, wouldn't this type of thing > already be possible with a macro today? > > Allen Madsen > http://www.allenmadsen.com > > > On Mon, Sep 24, 2018 at 11:34 AM Christopher Keele <christ...@gmail.com > <javascript:>> wrote: > >> That's a good point. I suspect the convention around manual usage would >> converge around: >> >> *def foo(%{x: x} = result when x > 1), do: 1* >> >> which parses as expected. This version feels more natural to me. >> >> I don't think the other form would accidentally be introduced while >> injecting one snippet of AST, because the tree would never be constructed >> the wrong way. String-based expression interpolation might make that >> mistake, but if you're metaprogramming with literal strings of code you've >> already made a mistake. >> >> I hadn't typed out an assignment case with inline guards, it does feel >> like it's doing too much in a short space with few grammar tokens to help >> understand it. That's a good argument for intentionally discouraging these >> constructs outside of metaprogramming, rather than adopting it as a common >> usage language feature. >> >> -- >> 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 elixir-lang-co...@googlegroups.com <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/elixir-lang-core/f2fafacb-3302-4c03-9b1b-ed766a896cc2%40googlegroups.com >> >> <https://groups.google.com/d/msgid/elixir-lang-core/f2fafacb-3302-4c03-9b1b-ed766a896cc2%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 elixir-lang-core+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/7fda093f-03b5-4d1d-9c16-73c9475ca6a7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
