You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
(The following is unverified internet content. Please verify before acting on it.)
Currently it looks like -- is handled rather poorly in split-args. It just searches for -- as a token and splits the sequence into "clean args" that precede -- and "extra args" that follow --. This doesn't take into account the possibility of supplying "--" as the value of a named option. That is, --foo=-- and --foo -- should be the same thing. (Unlikely to happen? Probably.)
Also, and more importantly, args following -- appear to be glommed onto the value of the final <option> in the parser (or subcommand). Not sure that that makes any sense. Worse yet, add! is used to add the args and add! makes no guarantee where the value will be added to a sequence; beginning? end? middle? Example:
test-positional-option-parsing failed
#["e", "--", "f"] = p5.option-value failed [#["e", "--", "f"] and #("f", "e") are not =.
sizes differ (3 and 2), element 0 is the first non-matching element]
Note that the actual parsed value is out of order: #("f", "e")
This is the simplest fix I could see for the second part ("Also, and more
importantly...") of dylan-lang#47 ... simply stuff everything after "--" into a new
`unconsumed-arguments` slot in the parser.
While technically this creates a backward incompatibility, the old code resulted in all
the arguments being added to the final option's value list **in reverse order** and it is
highly unlikely that anyone is depending on that broken behavior.
(The following is unverified internet content. Please verify before acting on it.)
Currently it looks like
--
is handled rather poorly insplit-args
. It just searches for--
as a token and splits the sequence into "clean args" that precede--
and "extra args" that follow--
. This doesn't take into account the possibility of supplying "--" as the value of a named option. That is,--foo=--
and--foo --
should be the same thing. (Unlikely to happen? Probably.)Also, and more importantly, args following
--
appear to be glommed onto the value of the final<option>
in the parser (or subcommand). Not sure that that makes any sense. Worse yet,add!
is used to add the args andadd!
makes no guarantee where the value will be added to a sequence; beginning? end? middle? Example:Note that the actual parsed value is out of order:
#("f", "e")
Pretty sure that
<positional-option>
values withrepeated?: #t
are lists and thatadd!
adds to the front of a list.The text was updated successfully, but these errors were encountered: