fix: --long= should not consume the next argument

[telemachus]

No description provided.

[telemachus]

I added a couple of tests to confirm that (1) for a boolean, --long= parses as true, (2) for other flags --long= parses as --long="", and (3) --long= does not consume the next argument from args.

In the parsing code, I tried to minimize changes, but while I was there I updated two comments to reflect that only long flags were at issue, and I changed len(args) <= 0 to len(args) == 0 since I don't think it's ever possible for a slice to have a negative length.

I considered adding a further test (like below) for --long="" with non-string flags, but I wasn't sure whether testing for such a specific error was too fiddly. Let me know if you think more tests are needed.

{
	Name:         "--flt= -a",
	Constructors: []fftest.Constructor{fftest.CoreConstructor},
	Args:         []string{`--flt=`, `-a`},
	Want:         fftest.Vars{WantParseErrorIs: strconv.ErrSyntax},
},

[ccoVeille]

The complexity of this code is outstanding

	if value == "" && !eqFound {
		switch {
		case f.isBoolFlag:
			value = "true" // `--foo` defaults to true
			if len(args) > 0 {
				if _, err := strconv.ParseBool(args[0]); err == nil {
					value = args[0] // `--foo false` should also work
					args = args[1:]
				}
			}
		case !f.isBoolFlag && len(args) > 0:
			value, args = args[0], args[1:]
		case !f.isBoolFlag && len(args) == 0:
			return nil, fmt.Errorf("missing value")
		default:
			panic("unreachable")
		}
	}

Unless I'm wrong, it could be this

	if value == "" && !eqFound {
		switch {
		case f.isBoolFlag:
			value = "true" // `--foo` defaults to true
			if len(args) > 0 {
				if _, err := strconv.ParseBool(args[0]); err == nil {
					value = args[0] // `--foo false` should also work
					args = args[1:]
				}
			}
		case len(args) > 0:
			value, args = args[0], args[1:]
		default:
			return nil, fmt.Errorf("missing value")
		}
	}

[telemachus]

You are not wrong. Thanks.

[ccoVeille]

There is also something strange with the code (the code that already exists)

Let's assume --foo expects a string

--foo leads to an error
--foo true leads to "true"
--foo=1 leads to "1"
--foo=false leads to "false"
--foo= leads to ""

But if --foo is a boolean

--foo false
--foo whatever
--foo 0
--foo 2
--foo=2

Leads to this

--foo=false
--foo whatever
--foo=false
--foo=true 2
an error

This behavior is strange to me, but I'm unsure how other libraries parsing flags do

[telemachus]

The difference between --foo 2 and --foo=2 is...not great. That is probably why flag in Go's standard library restricts the form --flag arg to non-boolean flags.

[ccoVeille]

Exactly

[telemachus]

I would be in favor of that here as well, but I think @peterbourgon wants to keep boolean parsing as is. (Also, that would probably be a very breaking API change now. Don't know how that plays with v4 being in beta.)

[telemachus]

@ccoVeille As a side note, flag in the standard library has a parallel inconsistency but for string flags.

	fs := flag.NewFlagSet("whatever", flag.ContinueOnError)
	cfg := struct {
		config  string
		// ...
	}{}
	fs.StringVar(&cfg.config, "config", "", "Use this configuration file")
	// ...

whatever -config=foo   # No error; config is set to "foo"
whatever -config foo   # No error; config is set to "foo"
whatever -config ""    # No error; config is set to ""
whatever -config=""    # No error; config is set to ""
whatever -config       # Error, namely "flag needs an argument: -config"
whatever -config=      # No error; config is set to ""

I think that the last two should return the same error, but they do not. I'm guessing this is because the parser would need to do extra work (not much but some) to detect the difference between -config= and -config="". I doubt anything can be done about it now (breaking API change), but I think it was a mistake.

[ccoVeille]

For me, the behavior of the stdlib is fine here. I might look a bit odd, but I'm fine with it.

It has its logic.

About ff lib, I don't know really. You are fixing a bug with the boolean flag after all, so fixing the bug is somehow already breaking something that was broken 😄, by fixing it.

While your fix is fine, I think the issue of removing the random behavior of boolean flag with a parameter should be considered, at least to have a library that behave like other libraries.

I don't think it was intended, I would remove it. But, except that your PR is fine, you are fixing the behavior with --foo= so nothing about --foo 0

So for me it can be merged as is

[telemachus]

@tgulacsi I appreciate the support, but I think we just have to wait for the maintainer to get a chance to review the changes and decide what he wants to do. I don't think that outside people approving will make much a difference one way or the other. (Though, that said, I'm happy for the code review!)

[peterbourgon]

Shouldn't this be

Suggested change

	{args: []string{"--xflag=", "--help"}, wantX: true, wantY: false, wantErr: ff.ErrHelp},
	{args: []string{"--xflag=", "--help"}, wantX: true, wantY: true, wantErr: ff.ErrHelp},

?

[telemachus]

@peterbourgon I see what you mean: yflag := fs.BoolDefault('y', "yflag", true, "another boolean flag"). I didn't notice that yflag defaulted to true. Sorry.

That said, here's something weird: the tests pass without error in all the cases below.

• {args: []string{"--xflag=", "--help"}, wantX: true, wantY: true, wantErr: ff.ErrHelp}
• {args: []string{"--xflag=", "--help"}, wantX: true, wantY: false, wantErr: ff.ErrHelp}
• {args: []string{"--xflag=", "--help"}, wantX: true, wantErr: ff.ErrHelp}

They all pass. I'm very confused. (I updated to wantY: true, but for some reason it doesn't seem to matter.)

[peterbourgon]

If wantErr is non-nil then the wantX and wantY fields aren't evaluated. My original comment was a bit pedantic, in that sense.

[telemachus]

Ah, okay. Either way, I clearly need to understand the test structure better.