C# Generics – Why Out Type is Generally Last

cgenerics

This is a bit of a subjective question I guess but I was hoping for opinions on either side of the argument.

So take this for example in C#:

public interface IFactory<Tin, Tout> : IFactory
{
    Tout Create(Tin param);
}

Now as you can see we take an input type and an output type, however a lot of frameworks often have a raft of different generics in these sort of cases where you often end up having TinOne, TinTwo etc to cope with multiple use cases. So even in the C# source it generally does <all input types, output type> however when you actually go to look at the implementations of interfaces like this, you generally (again subjective) want to know what the return type is, as that is often the contract you care about for the rest of the program, so it often makes it harder to find these interfaces in code due to the output type being last in the list not first.

So why was this approach taken? as personally I would find output being first being more logical, but I am sure there is a good reason why.

Best Answer

That's the way function types are normally written:

a → b

is a function that takes an a and returns a b.

(a, b) → c

is a function that takes a tuple of (a, b) and returns a c.

a → b → c

is a function that takes an a and returns a function that takes a b and returns a c (which is the curried version of the second function above).

In all these cases, the inputs come first, then the output. And it makes sense: data flows from input to output, types flow from input to input to output, and we read from left to right.

It also matches with declarations for subroutine prototypes in many languages. E.g. Scala:

// method:
def add(a: Int, b: Int): Int

// function:
(a: Int, b: Int) ⇒ { //body of the function, return type is inferred }

Go:

func add(a int, b int) int

Haskell:

add :: (Int, Int) → Int
-- or more idiomatically:
add :: Int → Int → Int

And so on.

Related Solutions

Go vs. C# – How Go’s Implicit Interfaces Improve Productivity Compared to C# Extension Methods

I don't see extension methods and implicit interfaces as the same at all.

First let's speak to purpose.

Extension methods exist as a syntactic sugar specifically to give you the ability to use a method as if it's a member of an object, without having access to the internals of that object. Without extension methods you can do exactly the same thing, you just don't get the pleasant syntax of someObjectYouCantChange.YourMethod() and rather have to call YourMethod(someObjectYouCantChange).

The purpose of implicit interfaces however is so that you can implement an interface on an object you don't have access to change. This gives you the ability to create a polymorphic relationship between any object you write yourself and any object you don't have access to the internals of.

Now let's speak to consequences.

Extension methods really have none, this is perfectly in line with the ruthless security constraints .NET tries to use to aid in distinct perspectives on a model (the perspective from inside, outside, inheritor, and neighbor). The consequence is just some syntactic pleasantness.

The consequences of implicit interfaces are a few things.

Accidental interface implementation, this can be a happy accident, or an accidental LSP violation by meeting someone else's interface which you didn't intend to while not honoring the intent of it's contract.
The ability to easily make any method accept a mock of any given object at all by simply mirroring that objects interface (or even just creating an interface that meets that methods requirements and no more).
The ability to create adapters or other various similar patterns with more ease in regards to objects you can't meddle at the innards of.
Delay interface implementation, and implement it later without having to touch the actual implementation, only implementing it when you actually want to create another implementor.

Java Generics – Using Raw Types in Method Signatures

Yes, you are. Generic wildcards enforce that the container contains "something, but we're not sure what" and raw types are just "the container contains objects".

So you can get some counterintuitive results,

List<?> wild = new ArrayList<String>();
List    raw  = new ArrayList<String>();
wild.add(1); // Compile time error
raw.add(1);
raw.add("Foo");
wild.add("string"); // Still a compile time error

Wild cards are represented as the same as raw at run time, but they are typechecked to make sure you never do something silly, like adding random objects to it.

So if you don't care about type safety, then yes, you can go ahead and use List, but for 3 characters, I'd just use the parameterized type.

Best Answer

Related Solutions

Go vs. C# – How Go’s Implicit Interfaces Improve Productivity Compared to C# Extension Methods

Java Generics – Using Raw Types in Method Signatures

Related Topic