multiple Go args sharing a single type in a function signature are mishandled

[josharian]

func f(a, b string)

"take arg air" takes "a, b string". It should take only a, and its removal range should be a, .

It's an interesting question what "pour arg air/bat" should do. Marking as to discuss to seek wisdom on that. Should be short (haha).

[josharian]

I think probably pour arg air should generate:

func f(a, , b string)

Although it could generate:

func f(a string, , b string)

---

pour arg bat probably should generate:

func f(a, b string, )

but there's an argument for

func f(a, b,  string)

[pokey]

What should "take arg bat" do? We usually include the type in the arg, so visually I'd expect b string, but for consistency with a I'd expect b. Not sure what is right

Cc/ @AndreasArvidsson here's another case where arg and item might differ

[pokey]

But I'd say whichever way we go, "pour arg bat" and "take arg bat" should be consistent

[josharian]

After further reflection, I think I want this...

---

"take arg bat"

    func f(a, b string)
//!           ^^^^^^^^

(Did I do that range correctly?)

"pour arg bat"

func f(a, b string, )
                    !

(How do I write selections in the scope test format?)

"drink arg bat"

func f(a string, , b string)
                 !

The rationale here is that it is easier to chuck an unwanted string than it is to bring one.

The user could just as easily also want:

func f(a, , b string)
          !

But as there's no clearly more likely outcome, it seems to be better to optimize to make it easier to fix what Cursorless chose, if it chose wrong.

"chuck arg bat"

func f(a string)

Can't imagine any realistic alternatives.

---

"take arg air"

func f(a, b string)
      [-]

The alternative is this:

func f(a, b string)
      [-]  [------]

which seems kind of crazy.

"pour arg air"

func f(a string, , b string)
                 !

The rationale is as above: Is easier to chuck a type than bring one.

"drink arg air"

func f(, a, b string)
       !

Uncontroversial, I think.

"chuck arg air"

func f(b string)

Again, uncontroversial, I think.

---

I'm not sure how consistent or inconsistent that is though.

At least now we have a lot of data points on the table to discuss. Looking forward to it.

[AndreasArvidsson]

I don't see a good reason why the type should be omitted from the argument scope.