One reason is that Kernel is imported everywhere by default and it contains core functions which other elixir constructs is built upon.

See the module documentation for Kernel

Yup. As commented on the linked thread:

Correct. Kernel was used to be bigger but we shrunk it before 1.0. The consensus was to keep those in Kernel precisely because they are the only ones available in guards.

Two other things to consider about this:

• If we allowed Map.size and Tuple.elem in guards, it would be extremely confusing to most why then we can’t use something like Map.get in guards. The lack of namespace reveals that there is something special about them. Today you at least know guards are a subset of Kernel. If we move them to modules, then any function that you have ever seen could be a guard.

• I could easily argue in favor of the guard functions because of #1 too. Imagine how verbose guards would be if each call in a guard had to be fully qualified

I think a good exercise to accompany your question is “how would the language look like if most guards were in potentially separate modules?”. Would it more or less confusing? How easy would it be to discover guards? If you rewrite some existing codebases to the proposed syntax, is it better? Worse?

Of the functions you mentioned, the only ones I would consider misplaced are apply/3 and apply/2, now that we have the Function module (hindsight is 20/20), and potentially get_in and friends, although I would still wonder where would be a good placement for the latter.

Thanks for the explanation!

This I have a different opinion on, though, as my only process to discover guards is “google for ‘elixir guards’ and read the list”. Since not all Kernel functions can be used in guards, the only guide I can use is the list of guard functions, and it wouldn’t matter then if they were in different modules. I do agree then reading a guard with Tuple.elem(tpl, 1) could lead to the confusion you mentioned, but finding out which functions are supported is already equally confusing.

Btw, we already have the X.y problem (not being a subset of Kernel) with defguard:

iex(1)> defmodule Foo do
...(1)>   defguard is_even(v) when is_integer(v) and rem(v, 2) == 0
...(1)> end
iex(2)> require Foo
iex(3)> defmodule Bar do
...(3)>   def baz(v) when Foo.is_even(v) do v + 1 end
...(3)>   def baz(v) do v - 1 end
...(3)> end

Possibly the Access module could be a good place for get_in etc

Personally I think that best way is to have Kernel.Guards which will contain delegates to other modules. Then we will have list of guards well documented in one module + all implementations will be in other modules like List or Map + we can automatically import Kernel.Guards as same as Kernel. I know that such changes will not come soon (if any), but I’m just curious what do you think about it @josevalim.

There are a couple issues here:

• Some (most) implementations will still need to be Kernel. For example, comparison/equality/arithmetic operators. Therefore, if we import both Kernel and Kernel.Guards, we will have conflicts
• Having both elem/2 and Tuple.elem/2 means two ways of doing the same thing
• The functions in Kernel.Guards are not available only in guards - this may be a documentation concern

I had in mind “normal” functions … I totally forgot about operators, sorry

For me it’s not a problem if we are using delegates - of course note that such function is delegated should exists in docs. It would be awesome if there would be a mark for it on summary functions list like: function(arg1, arg2) [delegate]

Then in Function section:

elem(tuple, index)                                                                                    [delegate]
elem(tuple(), non_neg_integer()) :: term()
This is delegated function for Tuple.elem/2

Personally I would like to see something like:

Kernel.Guards

This module groups special core functions which are allowed to be called inside guards, for example

# example defguard code here …

Nested guards

Guards allows also other guards to be called inside it, for example

# previous example
# example defguard which uses first example

Syntactic sugar in guards

Except functions grouped in this module and other guards we allow to use also arithmetic, comparison and equality operators which needs to be placed in Kernel module, for example:

# example defguard code with any operator

Old-way guards

Few words about macros here with a link to Macro module for more information …

Using guards

Few sentences about example usage in when and function body.

Summary

Summary content here …

Functions

Functions content here …

Of course I wrote it quickly, so this documentation will contain much more and much better text.

It is not a concern implenentation wise. Just from the point of view of the usage of the language. When would you use elem/2 and when would you use Tuple.elem/2?

It feels like we are adding more categories and distinctions? How are they helpful? Why do we care if a guard is coming from Kernel or another module?

This has one important difference - you need to call require, because it’s a macro. Similar with things defined using defguard, they can’t be “just called”, you need to explicitly opt-in to using them with require. Can you imagine requiring all the Tuple and Map and others to use the guards? Each module would be littered with those.