Flag-style arguments for Boolean parameters

[bandleader]

Looking to hear what people think of this feature and if it would help them. Many of my methods have optional Boolean parameters to set certain flags. Consider reading the following code:

Foo(, True, , , True)

But what do those Trues mean? You would have to look up Foo and check the signature. Turns out there are 5 optional Boolean parameters, and we are setting the 2nd and 5th to True.

We can already improve the legibility using named arguments:

Foo(ShowPreview := True, CrunchNumbers := True)

But it's verbose. I propose to simplify this into 'flag syntax:'

Foo(ShowPreview, CrunchNumbers)

(If there is a local symbol in scope called ShowPreview, that should be used first, to preserve backward compatibility. I think this a better solution than enforcing a hanging suffix after the flag name, i.e. ShowPreview :=.)

(I did not think of a good syntax for unsetting a flag that otherwise defaults to True, so the existing. FlagName := False would have to be used. !FlagName comes to mind, but it's not BASIC-like.)

Comments welcome.

[paul1956]

You could do !ShowPreview but in general I don't like the whole idea. I would rather see a CodeFix that fills in all the values. Foo(FirstParameter:=DefaultValue, ShowPreview := True, ThirdParament:= DefaultValue, CrunchNumbers := True) where DefaultValue is actually filled in. Without features in 15.5 getting better exposure I suspect most people don't name the parameters. Or just a QuickFix to name the parameter I click on.

[zspitz]

I would suggest that the primary issue here is less related to optional arguments, and more to passing literals into a method:

Public Sub Foo(SkipRows As Integer, TakeRows As Integer)
End Sub

Foo(5, 6) ' Are we skipping 5 rows and taking 6? Or vice-versa?

I think that any proposed solution for Booleans would have to apply to all literals..

[bandleader]

@zspitz Right, it's not related to optional arguments -- it's for any Boolean argument.

That said, it's not for arguments of other types (like your Integer example); the best solution for that is the existing named argument syntax -- Foo(SkipRows := 5, TakeRows := 6). Since you have to specify the integer value to pass, there's nothing more than we can shorten. My proposal is just to shorten that for Booleans, so you can skip the := value entirely and just say Foo(BoolArg2, BoolArg5).

[ericmutta]

@bandleader But it's verbose. I propose to simplify this into 'flag syntax:'

I can see where are you are coming from with this idea. Perhaps the verbosity issue could be improved via the IDE's autocomplete mechanism? For example:

In the above screenshot, the IDE is offering to complete the expected List(Of Dictionary(Of String, Integer)) given the data type of variable foo, but it also offers List(Of...). It could do something similar for optional parameters.

For example given:

  Public Sub bar(Optional ArgFoo As Boolean = True, Optional ArgBar As Boolean = False)
  End Sub

When you type bar( the autocomplete list could include the traditional ArgFoo:= and ArgBar:= as it currently does, but can also offer ArgFoo:=True, ArgFoo:=False, ArgBar:=True and ArgBar:=False so you can just pick one to have the whole thing typed out for you 👍

It would reduce the pain of the verbosity, without any changes to the language (something that I think we have all seen by now, is nearly impossible to do by filing issues in this repo!).

[reduckted]

I don't think this is really the same thing that you're asking for, but the latest version of ReSharper added Inline Parameter Name Hints. It looks like this:

It basically just renders the parameter name before the value. Perhaps something built into the IDE like this would help?

[KathleenDollard]

This is what named parameters are for. The verbosity is clarity.

The idea of a code fix that adds the named parameter, or an analyzer that disallows multiple values of the same type without named parameters, or the mini-entry that Resharper adds are all interesting. But for action, they should be entered on the Roslyn repo.

[bandleader]

OK.

@ericmutta's idea here of autocompleting :=True and :=False would be a nice touch -- and do feel free to file this in Roslyn -- but what I was after is the terseness, not saving the keystrokes. I always felt that one of VB's huge advantages was eliminating things like

CokeBottle cokeBottle = new CokeBottle(); -> Dim cokeBottle As New CokeBottle
and for (int x = 0; x <= 10; x++) -> For x = 1 To 10

(not to mention just eliminating semicolons...)