Is there some way to write ("overload") methods that vary only by returned value?

Question

--- UPDATE: ---
TL;DR
While it is not possible to have two methods (in the same context; e.g. in the same class) that differ only by their return type, it is possible to solve the problem a different way:

"Return" the value in an out parameter.

(C#) Bad:

// WON'T COMPILE
int myfunc() { ... }
double myfunc() { ... }

(C#) Good:

void myfunc(out int value) { ... }
void myfunc(out double value) { ... }

---

--- ORIGINAL QUESTION ---

Yes, this has strong similarities to "Generic interface overloading for methods". Thank you for finding that thread. Note however that it is not "an exact duplicate".

Please read the text bar that is inserted once a Q has been marked as a duplicate - it shows that the intent of "duplicate question" is to mark when a question is an exact duplicate of an existing question, and therefore adds nothing to SO. As I explain below, in response to the three proposed duplicates, this is incorrect (IMO). Instead of marking as duplicate, it would be more helpful to add either an answer or a comment linking to the related Q&A, and explaining the connection.

In that case, OP was working with generics, and it is not clear without delving into the details, that there mistake was trying to only differ by return type. Here, OP is focused on OVERLOADING, and thinks maybe the answer is Generics (it is not).

---

It is a mistake to consider this a duplicate of Q&A about method signature. Someone (including me, before) who didn't grasp that the solution to "overload + differ only by value returned" is solved by using an "out" parameter, is likely to only be confused by reading that Q&A.

Consider the mindset of someone who doesn't yet understand a topic. There is a difference between a related Q&A, which has answers that could be useful to someone if they were given an ANSWER here, which EXPLAINED how that other Q&A helps, and included a link to that Q&A, and a duplicate Q&A, which is a quite similar thread.

---

I do not see this as a duplicate of How to use generic method with "out" variable.

The reason it is different is because the goal is different.
Yes, the solution is an out parameter, but the goal is to find a way to overload methods differing only by the value returned.
For many years I have believed that doing so is impossible, because "return value is not part of the method signature."
However, I figured that with all the language enhancements, this might be possible now. (What I did not realize until today, was that it was possible to think about the problem in a different way. I figure I'm not the only one to be obtuse about this. Hence this Q&A.)

That other question only helps someone if they already know that the solution is an out parameter. (That question does not mention either "extension" or "return"/"returned value".)

---

I have a lot of VB read/write code that looks similar to this:

    Public Structure MyVertex
        Public Position As Vector3
        Public Normal As Vector3
        Public TextureCoordinates As Vector2

        Public Sub Read(br As BinaryReader)
            Position = br.ReadVector3()
            Normal = br.ReadVector3()
            TextureCoordinates = br.ReadVector2()
        End Sub

        Public Sub Write(bw As BinaryWriter)
            bw.WriteVector3(Position)
            bw.WriteVector3(Normal)
            bw.WriteVector2(TextureCoordinates)
        End Sub
    End Structure

where the Read/Write methods are extension methods, e.g.

Public Module ReadWriteExtensions

    <Extension()>
    Public Function ReadVector2(br As BinaryReader) As Vector2
        Dim v2 As New Vector2()

        v2.X = br.ReadSingle()
        v2.Y = br.ReadSingle()

        Return v2
    End Function

    <Extension()>
    Public Function ReadVector3(br As BinaryReader) As Vector3
        ...
    End Function

    <Extension()>
    Public Sub WriteVector2(bw As BinaryWriter, v2 As Vector2)
        ...

    <Extension()>
    Public Sub WriteVector3(bw As BinaryWriter, v3 As Vector3)
        ...
End Module

I know I can use "overloading" of parameter types to simplify the Write methods to have the same name. (I use "WriteT" to distinguish from the built-in BinaryWriter methods, but I could have simply used "Write".):

Public Sub WriteT(bw As BinaryWriter, v2 As Vector2)
    ...

Public Sub WriteT(bw As BinaryWriter, v3 As Vector3)
    ...

So usage becomes easier:

    Public Sub Write(bw As BinaryWriter)
        bw.WriteT(Position)
        bw.WriteT(Normal)
        bw.WriteT(TextureCoordinates)
    End Sub

But I have not done so, because I couldn't see how to do the equivalent to the "Read" methods. The obvious attempt fails because the methods vary only in return type:

<Extension()>
Public Function ReadT(br As BinaryReader) As Vector2
    ...

<Extension()>
Public Function ReadT(br As BinaryReader) As Vector3
    ...

Results in compiler error "Member with the same name or signature is already declared ...".

Is there some way to achieve the desired result?

(An answer for C# would also be useful.)

Answer 1

If you could have methods that varied only by return values, then how would you know for sure which method you were calling if the variable to which the result was assigned was implicitly typed or if multiple return types were assignable to the variable?

For example, suppose you had these three methods:

Public Function GetResult() As Object
   Return new Object()
End Function

Public Function GetResult() As SomeClass
    Return new SomeClass()
End Function

Public Function GetResult() As SomeOtherClass
    Return new SomeOtherClass()
End Function

If you do this:

Dim result = whatever.GetResult()

What will result be - Object, SomeClass, or SomeOtherClass?

Even if you could do this:

Dim result as SomeClass = whatever.GetResult()

What if SomeOtherClass inherits from SomeClass? Either one would be valid, so how would you know which one was returned?

But the worst part is that in these scenarios, if you could do this and the compiler attempted to infer which method you meant to call, then you could remove a method, your code would still compile, but removing that method would cause your code to call a different method. That's bad. If we remove the method our code calls, we want a compiler error. We don't want it to transparently guess at the next best method to call.

So one reason (I'm sure there others) is that if signatures could vary only by return type then the selection of methods could be ambiguous, harder to follow, and could change without warning.

---

On the other side, what is gained by ensuring that two methods have the same name? Giving things different names is a wonderful opportunity to add meaning to our code, and we should do it whenever we can. In fact, in cases where we are allowed to duplicate names, we often shouldn't. For example, we could decide that every method's first parameter should be a, the second should be b, etc. The compiler won't stop us from using a over and over again. But if we did we'd miss out on giving our parameters meaningful names that help others follow the code.

Or we could give all of our classes the same name, but in different namespaces. No compiler errors. But naming things is good, so if the compiler forces us to disambiguate a little with different names, that's also good.