"with_list_parse_key" environment parser does not support vector field

[TAYTS]

Not sure if I doing it wrongly or misunderstand the source code, the with_list_parse_key option is creating a map that will be used to check if a field should use list parser. In the case of vector of struct that contains vector field it is not possible to specify the key unless we specify all the possible index.

struct Nested {
    pub keys: Vec<String>,
}

struct Config {
    pub nested: Vec<Nested>
}

let env_source = Environment::with_prefix("server_config")
        .list_separator(",")
        // note: need to list all the possible index
        .with_list_parse_key("nested[0].keys")
        .with_list_parse_key("nested[1].keys")
        .try_parsing(true);

Is this the expected behaviour or could it be possible to support key like nested[*].keys?

[epage]

Currently, we only have one path syntax. The question would be whether we should only support wildcards here or if we could make it work to support wildcards in most places that take a path (and error otherwise). Should we also support this for keys?

I would lean towards general wildcard support. My maintenance of this crate is more passive, so someone wanting to see this done will need to take an active hand in investigating this and proposing a design (e.g. where all does path syntax apply, whether it makes sense to take a wildcard, what the behavior would be, the feasibility of meeting that behavior).

[TAYTS]

Let me try understand the codebase better and propose the solution

[TAYTS]

@epage Sorry for the delay, spent some time understanding the library, I think the full wildcard support might not be necessary and the use case might be rare.

The current get* API is returning &Value, if we want to support wildcard, we will need to return as Value given that we need to collect all the value and return as ValueKind::Array. This could impact the performance due to the cloning overhead. For set API, in most cases we would want to override a specific key rather a a group of keys.

I am thinking if we could simply just supporting the wildcard matching for the with_list_parse_key since it is simply used to determine if a key should be converted into a list or maybe a new API that accept a closure to determine if a key should be parse as list?

[TAYTS]

@epage I have associated both approaches to this issue as well