fix: accept empty IntSlice values

[lawrence3699]

Closes #222

IntSlice currently treats --data= as strconv.Atoi(""), so callers cannot use an explicit empty value to clear a slice while still distinguishing it from an omitted flag.

This change makes --data= resolve to a non-nil empty slice, matching the existing StringSlice empty-value behavior. It also adds regression coverage for the explicit empty-value case and for preserving a nil default when the flag is omitted.

Validation:

• go test ./...
• go test -race -v ./...

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[Copilot]

Pull request overview

Updates IntSlice flag parsing to support explicitly passing an empty value (--is=) without error, producing a non-nil empty slice so callers can distinguish “explicitly cleared” from “flag omitted” (closes #222).

Changes:

• Adjust intSliceValue.Set to treat an empty string value as an empty slice (instead of attempting Atoi("")).
• Add regression tests covering --is= behavior and ensuring a nil default remains nil when the flag is omitted.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
int_slice.go	Changes IntSlice parsing to handle empty string values as an explicit empty slice.
int_slice_test.go	Adds tests for explicit empty values and for preserving nil defaults when the flag is not provided.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[tomasaschan]

With this implementation, how would I pass an argument to make the resulting value be a singleton slice with an empty string? I know this code is intslice specific, but I don't think it we should introduce semantics where --data= means slices of different length depending on the type of the slice...

I might be misunderstanding, but if I'm not then this change (if applied to all slice types) just makes it possible to pass [] explicitly, at the cost of making it impossible to pass [""].

I agree that it's unintuitive that no value becomes a nonempty slice, but I don't think it's worth changing this behavior - especially not in a way that is subtly breaking (no compile time error, not test failures unless users of this library, or more likely users of Cobra, have an explicit test for the case of a user passing an empty value to their param, which seems very unlikely...) - just to change which value out of [] and [""] can be represented. If there is a way to extend behavior to allow new things without breaking old ones, I'm all ears.