This makes defining guards easier, since it does the boilerplate
for you and raises at compile time in the defguard macro when
you do something not allowed in guards (as opposed to whenever
the new guard happens to be used as a guard).
It takes a `defguard name(args) when implementation` invocation,
passes the implementation through `:elixir_expand.expand/2` in
a guard context, and if nothing is raised, transforms the impl
into a macro that works both inside and outside of guard contexts.
Signed-off-by: José Valim <jose.valim@plataformatec.com.br>
This is a first step to limiting recompilations in case a struct is used in a
module, the "parent module" of the struct changes, but struct definition itself
does not change.
Signed-off-by: José Valim <jose.valim@plataformatec.com.br>
* Whitelist which operators support next_break_fits
* No longer consider tuples as part of next_break_fits
* Do not consider eol for = and ::
* Do not consider eol for calls with one next_break_fits arg
We avoid using :file publicly as well as :location privately.
We do still use :file privately but that's supposed to mirror
the `-file` annotation in Erlang before function definitions.
We have reimplemented Enum.at/3, Enum.fetch/2, Enum.fetch!/2,
Enum.random/1, Enum.slice/2, and Enum.slice/3 to be more
efficient by using the new protocol function.
This partially implements #6955. We have decided to not replace
`count/1` by an `aggregate/2` callback because it became clear
we cannot implement `min/1` for date ranges since `Enum.min/1`
does a structural comparison. Given ranges are still the only case
that requires custom aggregations, we have decided to inline those
in Enum until we have more evidence that such callback is necessary.
Erlang's typespecs define only cover_compiled and preloaded
as valid atoms and uses an empty list for generated code.
So we should follow Erlang's rules until we can officially
relax them.