将命名参数与 ParamArray 冲突

Conflict using named parameters with a ParamArray

我已经用这些参数写了一个方法:

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

上面的代码中,参数的名称只是一个例子, 在我的实际代码中,参数的名称是描述性名称,我将使用命名参数进行注释以编写易于理解的代码,因此按照上面的示例方法,我将这样写:

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

但是,这将失败并出现编译器错误,指出 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:="...",
           {"...", "..."})

我将此附加到与 Microsoft 相关的语言语法行为中的设计冲突,因为我可以看到他们让程序员解决这种情况的唯一方法是这些不漂亮的解决方案:

也许存在另一种我缺少的解决方案来保留带有命名参数的 ParamArray

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

不,没有。并且有充分的理由 - ParamArray 是特定方法作者的考虑因素。命名参数是 调用者 方法的考虑因素。它们的运作方式不同 "level",您已经链接到的文档表明它们不能轻松共存的原因很充分。

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.

通常,此类样本应与描述该方法的文档放在一起。如果它们都在同一页面上,那么当用户感到困惑或需要查看定义时,他们可以轻松地再次找到该定义。

相反,决定在整个文档中使用命名参数更可能是混淆而不是教育。您的示例代码看起来与其他代码示例明显不同,例如微软或大多数其他地方。这会立即让初学者感到困惑(如果他们还不熟悉命名参数),或者他们会形成错误的印象,例如 "I have to use named arguments with this library. I wonder why?"