allow distinguishing between argument not passed vs argument passed and equal to default about cligen

[c-blake]

AFAIK, Nim procs themselves cannot distinguish if they were called with an explicit value or got the default. That implies the proc in question must know it is a command. In that case we can just have the parser populate a Table (or HashSet) with actually passed commands and the proc can test if they were passed with if "foo" in myProcNamePassed. A Table with a list of values might be more general.

[c-blake]

(I should have said "an explicit value that happens to be the default", of course.)

Thinking about this a little more -- I would say that it is NOT A GREAT IDEA IN GENERAL since it may make the wrapped proc uncallable as an API call from other Nim code. I think of the encouraging retention of API callability as a truly "system positive" feature of cligen, but if it's just for some proc main() and just for a CLI, and you don't care about Nim callers, and it's for backward compatibility, then, eh...There is a way to do it already by redefining argParse for the type of the parameter in question:

import cligen, cligen/parseopt3, cligen/argcvt, strutils, parseutils

var alphaSet = false

proc argParse(dst: var int, dfl: int, a: var ArgcvtParams): bool =
  if a.key == "a" or optionNormalize(a.key) == "alpha":
    alphaSet = true
  let stripped = strip(a.val)
  if len(stripped) == 0 or parseInt(stripped, dst) != len(stripped):
    ERR("Bad value: \"$1\" for option \"$2\"; expecting $3\n$4" %
        [ a.val, a.key, "int", a.help ])
    return false
  return true

proc foo(alpha: int=1, beta: int=2) =
  if alphaSet:
    echo "alpha set changed by user"
  echo alpha, " ", beta

dispatch(foo)

That gets you specificity for any name and any type you want and since I think it's a bad idea in general, that is probably enough support for it.

[c-blake]

Well, I went ahead and added an easier approach for this, but I would strongly encourage only very judicious have-to-use usage.

[c-blake]

Oh, and see test/DetectSet2.nim for a full example. Rather than some binary thing like, well, really all of your proposals, this solution lets the CLI author see the full sequence of unconverted string values that the parser saw for any given parameter name. If certain parameters are string data not needing any conversion that's full information.

To show the CLI author converted values would also be nice, and what would be needed there is also what would be needed to completely separate parsing from dispatching. E.g., you could just have the parser return a Table[string, seq[Any]]. That Any could be some variant type that we synthesized on a per-wrapped-proc basis from the types of values in the parameter list. Then you generate both a parser and a dispatcher where the usual for-dummies mode is dispatcher(parser()). Or even better the parser could be "updating" such that it updates a Table[string, seq[Any]] from the seq[string]. Then it could even be called more than once and tag each value in the seq[Any] with a "source" like config file, environment, command { so really maybe more seq[tuple[source: int, value: Any]] }.

I'm not quite sure if this is actually possible, though..at least not without requiring users to enter type names which IMO would sacrifice a lot of usability. cligen currently leverages the type inference Nim can do for param=def in parameter lists and var param=def. So, right now, CLI authors don't need type names in signatures. I think you would need a type name to define that Any variant. Also, it would probably be a lot of work -- close to a total re-write.