Bryan Green wrote:
Vladimir Prus writes:
5. For + // A value is optional if min_tokens == 0, but max_tokens > 0. + // If a value is optional, it must appear in opt.value (because + // it was 'adjacent'. Otherwise, remove the expectation of a + // non-adjacent value. + if (min_tokens == 0 && max_tokens > 0 && opt.value.empty()) + --max_tokens; +
what will happen if in future, there's some option that accepts [0,10] tokens. Your code will make it access [0,9] tokens, IIUC. Maybe you should explicitly check for max_tokens == 1?
My intuition was that it is not possible to have an option that accepted [0,10] arguments without raising ambiguities, unless it used an extension [to the implicit_argument format. When checking how 'multi_token' worked, I found that it in fact doesn't work (ticket #1132).
Yea, it's broken now.
The extension I envision would use commas as delimiters, such as:
--do-something=again,and_again,with_feeling_this_time
Under special circumstances, I can see a way to eliminate the ambiguity in multitoken - you just need a unique marker indicating the end of the option: either the leading '-' of the next option, or EOL, or some user-defined delimiter that identified the beginning of positional parameters.
If such a future possibility is preferable over the suggested implicit_argument method for multiple tokens, I'd be happy to change the check to be (max_tokens == 1).
I'm presently thinking that multitoken option should stop on any token that looks like an option. That includes "--" -- which can be used to terminate the list of options and start positional options. So yes, I think max_tokens == 1 will be right now for. - Volodya
Regards, Bryan