[jitter_]

I'm not here to pick a side. I'm sure all of us can be more friendly to each other.

However, I'm a bit curious about when you say

> Suggesting that someone pours over documentation (and laughably source code) to explain patterns (or a lack thereof) in a highly abstracted language is counter-productive.

Isn't that what documentation is for? To learn about whatever's being documented. What would you suggest would be the better way to convey this information?

For source code, I can see your point. Although in my experience source code has the benefit that you can be certain that it doesn't lie. It does exactly what it says. Sometimes this can be a really nice benefit when trying to figure out what's going on. Regardless of the language or environment you are in.

[Supermancho]

> Isn't that what documentation is for?

I would agree, if everything was documented. The issue at-hand is what is not explicitly documented. What constitutes a guard-worthy function? ie A pure javadoc without any notation about what the API does, is not sufficient.

[josevalim]

> The issue at-hand is what is not explicitly documented. What constitutes a guard-worthy function?

https://hexdocs.pm/elixir/1.15/patterns-and-guards.html#guar...

Plus the docs lists on the sidebar which custom functions are guards. Examples: https://hexdocs.pm/elixir/1.15/Integer.html#guards

[Supermancho]

The question was about why not what is allowed as a guard. Perhaps this was not clear amongst the noise.