This aligns the behaviour with atoms keys and maps
for state without forcing everyone to pick one or
the other.
For clarity, developers can always use required/optional.
Closes https://github.com/elixir-lang/elixir/issues/8564
This is my first attempt to contribute code to elixir, so please forgive me if this PR is completely naive.
Besides adding the `is_list/1` guards, I have updated the error message to specify that record specifications must use an atom `literal` as the name, to make it clear that the type `atom` is also not valid.
Both sides of the range must be integers (after expansion), and
the "first" value must be greater than the "last" value.
These checks were previously performed by erl_lint.
We are uncertain this is the best API to expose this
information. Maybe it is best to expose this as a separate
calendar. That uses the week-based year and week-based
month in the Date/Time structs.
This fixes issue #8450 which was caused by the user of
`system_time` when `os_time` should have been used.
This commit improves the touch API by also allowing
posix times in `File.touch/2` and also document its
defaults. With this change, we phase out the remaining
use of Erlang's `:calendar` module in Elixir.
This way if the term is a function that couldn't be found because it's
referencing an anonymous function from a previous version of a given
module, it says as much instead of saying it expected a function.
Prior to this patch, if a module depends on the struct of
another module and that other module depends on the struct
of the first module inside typespecs, it would lead to a
compiler deadlock, which this deadlock would not happen
in "regular code".
This commit also adds a test to ensure @enforce_keys are
not enforced when expanding typespecs.
For now, we are using a compiler private API, but we should
provide a public version for it in a future commit.
- General improvements to docs
- Minor grammar corrections
- Add doc test examples to Version.match?/3 using :allow_pre option
- List all the operators allowed in requirements.
- Mention that the PATH part of the version can be used as operand with ~>
- Make a clarification that "`~>` will never include pre-release versions of its upper bound,
regardless of the usage of the `allow_pre:` option", and add tests to verify this
- The requirement table has been update:
- It doesn't use the consecutive PATCH number in the example, so `~> 2.1.2` will not use
`2.1.3-dev` but `2.1.6-dev` to make it that the upper bound is within the MINOR part
not the PATCH one
- Remove "-" and replace with "`true` or `false`" as it is not clear what "-" means in that example,
and it could be understood that the option is not allowed in that example.
- Updated to "`true` or `false`" the cases whether both options return the same value.
- Added an additional example: `>= 2.1.0` | `2.2.0-dev` | `true` | `true`
- Replace "two element tuples" with "two-element tuples" for every number in 1..10
- Replace "2-element tuples" with "two-element tuples" for every number
- "1-based" with "one-based"
- "0-based" with "zero-based"
José Valim
nico piderman
Fernando Tapia Rico
José Valim
Dennis Beatty
Michał Muskała
Eksperimental
HUANG Wei
Xavier Noria
Kip Cole
Lau Taarnskov
Hans
Devon Estes
Wojtek Mach
Sun Yaozhu
Eric Meadows-Jönsson
Mitchell Hanberg