Conflict using named parameters with a ParamArray

Question

I have written a method with these parameters:

Sub MethodName(ByVal paramName1 As String,
               ByVal paramName2 As String,
               ByVal paramName3 As String,
               ByVal ParamArray lastParam As String())
End Sub

In the code above, the name of the parametes are just an example, In my real code, the name of the parameters are descriptive names that I will remark using named parameters to also write comprehensible coding, so following the example method above I will write something like this:

MethodName(paramName1:="...",
           paramName2:="...",
           paramName3:="...",
           lastParam:={"...", "..."})

However, that will fail with a compiler error saying that Named arguments cannot match ParamArray parameters, but as I have written named arguments for the other params then I cannot let the last parameter without a name in this way below, because then, another compiler error says Named argument expected:

MethodName(paramName1:="...",
           paramName2:="...",
           paramName3:="...",
           {"...", "..."})

I attach this to a design conflict in the language syntax behavior related to Microsoft, because the only way I can see that they let the programmer to solve this scenario are one of these unpretty solutions:

Write a common parameter (an Optional parameter) instead a ParamArray.
Do not use named arguments for any argument.
Ignore the usage of the last parameter in the code examples above.

Maybe exists another solution that I'm missing to preserve a ParamArray with named arguments?.

Another approach: If you have a method which need to use named parameters, maybe this a good sign to convert method to class and use properties — Fabio, Mar 08 '16 at 05:01
Another approach for methods: use describable names for variables passed to the method, then you don't need named parameters :) — Fabio, Mar 08 '16 at 12:49
Why is "Do not use named arguments for any argument" an "unpretty" solution? - it's by far and away the most common way in which most methods are called. — Damien_The_Unbeliever, Mar 08 '16 at 13:41
@Damien_The_Unbeliever Is very "unpretty" when building an API help file, where you prefer to denote the parameter names using named parameters in code samples for beginner people, to make it more friendlly to understand the purpose of each parameter (together the parameter documentation of course). Thanks for comment. — ElektroStudios, Mar 08 '16 at 14:42
@Fabio Thanks for comment too, my parameter names are already describable, I just would like to use them as named parameters, all of them. — ElektroStudios, Mar 08 '16 at 14:43
I believe the limitation on using a named argument for ParamArray parameters is a carry-over from VB6. I had assumed that there was some edge-case (that I could not think of) where the usage of a ParamArray named argument would cause ambiguity in the intent. However, C# added named arguments in VS2010 and it does not enforce this constraint, so that destroyed my edge-case theory. — TnTinMn, Mar 08 '16 at 16:03

score 2 · Accepted Answer · answered Mar 08 '16 at 14:56

Maybe exists another solution that I'm missing to preserve a ParamArray with named arguments?

No, there isn't. And for good reasons - ParamArray is a consideration for the author of a particular method. Named Arguments are a consideration for callers of methods. They don't operate at the same "level", and the documents that you're already linked to indicate that there are good reasons for why they can't coexist easily.

when building an API help file, where you prefer to denote the parameter names using named parameters in code samples for beginner people, to make it more friendlly to understand the purpose of each parameter.

Usually, such samples should be co-located with the documentation that describes the method. If they're both on the same page, then the user can easily locate the definition again if they are confused or need to see it.

Deciding, instead, that you're going to use named arguments throughout your documentation is more likely to confuse than educate. Your sample code will look distinctly different from other code samples from e.g. Microsoft or most anywhere else. That will either straight away confuse beginners (if they're not yet familiar with named arguments) or they'll form mistaken impressions such as "I have to use named arguments with this library. I wonder why?"

Is a good conclusion the ending phrase with quotes , hehe, maybe really could be better to avoid the usage of named params. thanks for answer. — ElektroStudios, Mar 08 '16 at 16:09

Conflict using named parameters with a ParamArray

1 Answers1