Proposal: add :guards option to import/2

[eksperimental]

Hi,
Currenly import/1 allows us to import :functions, :macros, :sigils with
the :only option.
I have found myself to manually have to list every guard I want to
import from my "Util" module. This has been a recurring issue.

I think it will be a good addition given the nature of guards that
since they are macros they need to be required, plus usually you
don't want to have the module name when you call the guard.

What do you guys think?

[Kenny Evitt]

So the `:guards` option would only import guard macros?

Should this option also import guards that are NOT defined using `defguard` or `defguardp`?

[eksperimental]

As of now, when you define a guard with `defguard` it adds the
attribute: `@doc guard: true`, we could include guards that are defined
with `defguard` and any other macros with this attribute set. Or we
could introduce a new attribute for identifying guards, as @doc seems
limited to documentation only.

`defguardp` are private so they wouldn't be available to be imported.

[Kenny Evitt]

Those are good details to know – thanks!

And thanks for pointing out my 'brain fart' about `defguardp`.

Would you think it would make sense to _exclude_ any 'guard macros' either NOT defined with `defguard` nor having whatever relevant attribute there might be? I'm trying to think how useful this request/proposal might be for others. Personally, I'm generally happy to just `import` specific macros/guards if it doesn't make sense to just import entire modules.

I would think `import`-ing a module would also include any guards (of any variety) – is that no so?

[eksperimental]

> Would you think it would make sense to _exclude_ any 'guard macros'
> either NOT defined with `defguard` nor having whatever relevant
> attribute there might be?

How would you make the distinction between a guard and a regular macro?

> I'm trying to think how useful this
> request/proposal might be for others. Personally, I'm generally happy
> to just `import` specific macros/guards if it doesn't make sense to
> just import entire modules.

My use case if that usually the only thing that I import from an
`*.Util` module are the guards

> I would think `import`-ing a module would also include any guards (of
> any variety) – is that no so?

Well, `import only: :macros` would import the guards, since they are
macros, but it will also import any other macro that may you have.

On Mon, 13 Jun 2022 12:25:27 -0700 (PDT)

[José Valim]

> How would you make the distinction between a guard and a regular macro?

This is exactly the root issue for me. :( I am not sure if we should rule out macros, just because they are not written with defguard.

--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/62a79330.1c69fb81.761ec.1654SMTPIN_ADDED_MISSING%40gmr-mx.google.com.

[Kenny Evitt]

I don't know the details about practical means of distinguishing between guards and regular macros – sorry!

(I also didn't realize when I wrote my previous reply that you were the same person that created this post – sorry for that too! I've been bouncing around a bunch of different things so far today.)

Your suggestions for how to make those distinctions seem reasonable – but I was just curious; not anyone with any particular expertise about Elixir or how it's implemented.

It does seem like there are special guard-only compile time checks, e.g. that apply to 'regular macro guards' too, which seems suggestive about there being some way to do all of this.

> My use case if that usually the only thing that I import from an `*.Util` module are the guards

> Well, `import only: :macros` would import the guards, since they are macros, but it will also import any other macro that may you have.

Got it – thanks! I think your proposal seems perfectly sensible. I don't know what implementation tradeoffs it would involve tho.

And you've inspired me to investigate at least a little whether my own Elixir projects could helpfully use some custom guards – thanks for that too!