Closed idanarye closed 11 months ago
I'm also considering adding helper functions like iter_if_sub
for the other style, but I'm not 100% sure yet if iter_if_sub
is the correct abstraction...
I think I'd add:
impl AttrArg{
try_get_value(self) -> Result<Expr, /*Error that says a key value was expected*/>;
try_get_subcommand<T: Parse>(self) -> Result<impl Iterator<T>, /*Error that says a subcommand was expected*/>;
try_get_flag(self) -> Result<bool, /*Error that says a flag was expected*/>;
}
as AttrArg
knows the ident, it can also set the correct span easily.
My iter_if_sub
is similar to your try_get_subattr
, but now that I think about it,
for arg in expr.iter_if_sub()? {
is not that much simpler over
for arg in expr.subattr()?.args()? {
So maybe I should just have flag()
, keyvalue()
, and subattr()
methods? The naming convention comes from how Result
has ok()
and err()
methods. The semantics are a bit different (they return Option
while I return Result
, but the idea is similar.
I also want to have _or_nullify()
version of all these methods, which will accept a &mut Option<T>
and handle AttrArg::Not
.
BTW - I'm thinking that nested
would be a better name than sub
. I'll keep it sub
for now since it's internal API, but I might rename it after #116 gets in.
Actually, _or_nullify
is a problem because it must still return a value (which does not exist) or an error. Maybe or_not()
, which would return and Option
?
Actually,
_or_nullify
is a problem because it must still return a value (which does not exist) or an error. Maybeor_not()
, which would return andOption
?
that makes more sense, I find apis taking &mut to be a bit clunky
@ModProg - I've taken your
AttrArg
idea and modified it so that the name will be matched first. This means that if a setting is used with the wrong style, instead of getting an error that it does not exist we'd get an error that it is of the wrong type. Currently this error does not specify what the correct type is, but that can be added in the future.