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). 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). Regards, Bryan