This potentially improves compile times a bit. The only thing the
function needs is the `META` structure of `C`, which can be passed from
the outside. The function is still generic over the formatter, but only
three specific ones are passed. So maybe it's just compiled for those
three already? One might also think about using dynamic dispatch for
the formatter.
Though compile times are likely dominated by all the generated code,
especially the serde-derive code.
I think this is an overall improvement. A few things done here:
- They are available as `::env::parse` instead of `::env_utils`. The
`env` module gets functions of its own soon enough.
- Renamed functions to be shorter: `list_by_sep`, `list_by_comma`, ...
- The docs were adjusted. One example is enough. And the functions with
a fixed separator don't need the full docs again. That way we can
avoid the `paste` dependency.
- Functions now always return `Result<C, _>`. While the previous version
was slightly more flexible, I don't think anyone would benefit from
that flexibility (as `parse_env` requires `Result<_, _>` anyway) and
this way it's a bit clearer what the function does, especially for
those who don't know the nifty `FromIterator for Result` impl.
- The example was adjusted accordingly. I also changed the names to
obviously dummy names as I didn't know the existing names and don't
want to spend time investigating whether I want their names in my
code base :D
Since there is no established format for representing collections within env variables, to enable their support, the feature with a custom parser attribute added.
Add helpers for parsing env variables into collections
Improve rustdoc for `env_utils` functions
Improve `parse_env` example
This is to make adding fields to those structs a non-breaking change.
This unfortunately means that users cannot use the struct initializer
syntax anymore. They have to create a mutable variable and change fields
that way. It's slightly annoying, but I think we want `non_exhaustive`.
Also, there are multiple discussions and pre-RFCs for letting Rust allow
the struct initializer syntax when the type implements `Default`. So
maybe this will improve in the future.
This gets rid of a lot of duplicated logic that was previously
copy&pasted. This commit alos:
- Makes it easier to implement new formats
- Gets rid of a few bugs
- Makes the system more flexible (more options)
- Adds a lot of additional tests
Fixes#2
I simply forgot to use the `deserialize_with` attribute for the env
deserialization. The previous code was somewhat weirdly coded in that
we would always deserialize `Option<T>` (as it's a partial type) and
the "env variable not present" info would travel through the
deserializer to the `Option<T> as Deserialize` impl. Now it's more
straight forward.
Regarding nested fields: I cannot imagine a situation where that
distinction is useful. Also, specifying an empty nested object looks
stupid in TOML and YAML anyway.
Regarding default fields: If there is a default value, then the field
should not be declared as optional to begin with.
