A somewhat common pattern when using cloud is to have a command like /do_something [user], where when the user argument is omitted the command sender is used instead, but only if it's of the appropriate type, otherwise failing parse.

Up to now the best solution to implement something like this was to split up the command into two:

• /do_something: only allows specific sender type
• /do_something <user>: allows any sender type

and/or implement validation/default value logic in post-processors or command handlers themselves.

This works fine but is a little cumbersome and confusing for new users.

Allowing dynamic default values to return an ArgumentParseResult<T> seems like it might be a nice alternative.