> An alternative (or complementary) approach to function types, suggested by some early proposals, would have been to introduce a new, structural function type. A type like "function from a String and an Object to an int" might be expressed as (String,Object)->int. This idea was considered and rejected, at least for now, due to several disadvantages:
Too bad they didn't, C# originally had delegates that you had to declare, but with the addition of generics and lambdas, that system got prettier and easier. The generic delegate types Func and Action are just that, so I can have a method that looks like this:
...which means that MyMethod is a method that takes two arguments, the first is a string, and the second is a method that takes two arguments, a string and an int, and returns a Bar object. But when I call it, I can use a lambda expression, like this:
var result = MyMethod("hey hey", (s, i) => new Bar(s, i));
...which is far from unwieldy. But I can see how checked exceptions would make it horrible, and I'm glad C# doesn't have those.
Too bad they didn't, C# originally had delegates that you had to declare, but with the addition of generics and lambdas, that system got prettier and easier. The generic delegate types Func and Action are just that, so I can have a method that looks like this:
...which means that MyMethod is a method that takes two arguments, the first is a string, and the second is a method that takes two arguments, a string and an int, and returns a Bar object. But when I call it, I can use a lambda expression, like this: ...which is far from unwieldy. But I can see how checked exceptions would make it horrible, and I'm glad C# doesn't have those.