CC @robpike

The flag package serves well for the uses it's intended for. Given the depth of analysis you have done, I think what you're really looking for is a more capable replacement. I would prefer we don't add more (and more confusing) features to the existing interface.

Also, given the way flags are interpreted, I do not believe it is possible in general to ignore unknown flags, which is a strong argument against adding this feature.

I don't think it's possible to ignore unknown flags either, an argument passed to a flag can start with a -.
Example:

cmd -known1=val1 -featuregates=-featureA -known2=val2
cmd -known1 val1 -featuregates -featureA -known2 val2

If -featuregates isn't a registered flag, -featureA is ambiguous and it would be incorrect to treat it as a flag.

How about adding an extra callback instead of extending the enum? A callback would get the tail of unprocessed args and returns an int, telling how many args the callback consumed (= how many args flag core can skip). If a user callback returns 0 it means falling back to the default ExtraHandling processing.

IMHO this would give users freedom of handling arguments, at the same time not bloating flag with extra logic.

Such user callback might look like this:

integration := func(args []string) uint {
  switch args[0] {
     case "-serviceAparam", "-oddWindowsFlag":
        return 1
     case "-serviceBparam":
         if len(args) > 1 && args[1] == "--foobar" {
            return 2
         }
         return 1
     default:
        return 0
  }
}

Flag.ErrorHandlingFunc = integeration

It still seems to me that a richer, externally provided flags package is what you're after. The one in the standard library is deliberately minimalist.

Personally, I'm fine with flag. However, since functions are first-class things in Go, I'd choose custom functions over additional enum values if the proposal got proceeded.

I don't think it's possible to ignore unknown flags either, an argument passed to a flag can start with a -. Example:

cmd -known1=val1 -featuregates=-featureA -known2=val2
cmd -known1 val1 -featuregates -featureA -known2 val2

If -featuregates isn't a registered flag, -featureA is ambiguous and it would be incorrect to treat it as a flag.

@seankhliao I tested the case where a - directly follows an =: https://go.dev/play/p/wp1h3wN6bCv
From this sample, it looks like flag will treat everything from the right of = to the next space as the flag's value.

In your first example:
at -featuregates
-> skip up to the next space (skip -featuregates=-featureA )
-> land on -known2=val2 and keep parsing

Second example:
at -featuregates
-> skip up to the next space (skip -featuregates )
-> land on -featureA -known2 val2 and keep parsing
-> skip up to the next space (skip -featureA )
-> land on -known2=val2 and keep parsing

Both use the same approach of skipping until the next space, and both should parse -known2 correctly.

How about adding an extra callback instead of extending the enum? A callback would get the tail of unprocessed args and returns an int, telling how many args the callback consumed (= how many args flag core can skip). If a user callback returns 0 it means falling back to the default ExtraHandling processing.

IMHO this would give users freedom of handling arguments, at the same time not bloating flag with extra logic.

Such user callback might look like this:

integration := func(args []string) uint {
  switch args[0] {
     case "-serviceAparam", "-oddWindowsFlag":
        return 1
     case "-serviceBparam":
         if len(args) > 1 && args[1] == "--foobar" {
            return 2
         }
         return 1
     default:
        return 0
  }
}

Flag.ErrorHandlingFunc = integeration

@WojciechMula Thanks for considering this issue. Your solution solved the problem, but I'm looking for a minimalistic solution which matches the style of flag. Your example seems a bit verbose, compared to passing an option to KeepParsingFlagsOnError.

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

As people have noticed, this is infeasible because you don't know whether an unrecognized flag takes arguments or not. Plenty of flags take flag-like arguments, like -ldflags=-w in the go build command, which could be written go build -ldflags -w. And parsing needs to stop at the first non-flag argument, not keep going. Consider go test -asdf pkg -foo. We can't assume -asdf takes pkg as its argument and continue on to -foo.

Based on the discussion above, this proposal seems like a likely decline.
— rsc for the proposal review group

Thanks @rsc for taking a look at this proposal.

I recently discovered that pflag implements this feature already. (code)

Likely they have the same issues as described in @rsc 's earlier comment. However, their solution works for me because I, as the binary author, can guarantee that there are no sub commands when parsing args. I think if you can guarantee that the command is a leaf node in the command tree, then it's safe to ignore unknown flags with the algorithm I originally posted.

It still seems to me that a richer, externally provided flags package is what you're after. The one in the standard library is deliberately minimalist.

@robpike 's earlier comment rings true: golang users who are interested in this functionality are best suited to use a richer flag parser than the deliberately minimalist one.

This proposal has been declined as retracted.
— rsc for the proposal review group