Overloading problem

  • Thread starter Thread starter Armin Zingler
  • Start date Start date
A

Armin Zingler

Hi group,

why can't I overload these procedures?

Private Sub proc(ByVal arg As String())
End Sub

Private Sub proc(ByVal ParamArray arg As String())
End Sub

IMO, the compiler must be able to distinguish between them because it
depends on the *call* which procedure is called:

Dim s As String() = {"a", "b"}

proc(s)
proc("a", "b")

In the 1st call, the arg is a string-array, in the 2nd there are several
strings put into a string array. The result is the same, but the call is
obviously different. I think this is not ambiguous for the compiler.
 
Armin,
why can't I overload these procedures?

Because the ParamArray keyword is just a syntactic shortcut for the
ParamArrayAttribute. Perhaps it's more clear when you see it as

Private Sub proc(ByVal arg As String())
End Sub

Private Sub proc([ParamArrayAttribute] ByVal arg As String())
End Sub

An attribute doesn't differentiate the signatures.


This is a valid call to both of your methods, so it is indeed
ambiguous.



Mattias
 
Mattias Sjögren said:
Armin,
why can't I overload these procedures?

Because the ParamArray keyword is just a syntactic shortcut for
the ParamArrayAttribute. Perhaps it's more clear when you see it as


Private Sub proc(ByVal arg As String())
End Sub

Private Sub proc([ParamArrayAttribute] ByVal arg As String())
End Sub

An attribute doesn't differentiate the signatures.


This is a valid call to both of your methods, so it is indeed
ambiguous.

IMO, only the first overloaded version is valid with "proc(s)" because the
second version expects a list of strings. s is not a list of strings. For me
the difference is obvious, why not for the compiler?
 
* "Armin Zingler said:
why can't I overload these procedures?

Because the ParamArray keyword is just a syntactic shortcut for
the ParamArrayAttribute. Perhaps it's more clear when you see it as


Private Sub proc(ByVal arg As String())
End Sub

Private Sub proc([ParamArrayAttribute] ByVal arg As String())
End Sub

An attribute doesn't differentiate the signatures.


This is a valid call to both of your methods, so it is indeed
ambiguous.

IMO, only the first overloaded version is valid with "proc(s)" because the
second version expects a list of strings. s is not a list of strings. For me
the difference is obvious, why not for the compiler?

Mhm... Even if there was no ambiguity, I would not want to be prevented
from calling a method that expects a paramarray by passing an array
instead of explicitly typing a list of params.
 
Herfried K. Wagner said:
* "Armin Zingler said:
why can't I overload these procedures?

Because the ParamArray keyword is just a syntactic shortcut for
the ParamArrayAttribute. Perhaps it's more clear when you see it
as


Private Sub proc(ByVal arg As String())
End Sub

Private Sub proc([ParamArrayAttribute] ByVal arg As String())
End Sub

An attribute doesn't differentiate the signatures.


proc(s)

This is a valid call to both of your methods, so it is indeed
ambiguous.

IMO, only the first overloaded version is valid with "proc(s)"
because the second version expects a list of strings. s is not a
list of strings. For me the difference is obvious, why not for the
compiler?

Mhm... Even if there was no ambiguity, I would not want to be
prevented from calling a method that expects a paramarray by passing
an array instead of explicitly typing a list of params.

That's why it should be overloaded.


Meanwhile I understood Mattias' point: The problem is not that the compiler
can not distinguish between the calls, but the problem is that both
signatures are the same, and this is not possible. So, it's not a resolving
problem but a declaration problem. Anyway, it's not so important because a
new string() can easily be created.
 
Back
Top