Lambda Expressions vs. Anonymous Methods, Part Two

Community Convergence XVIII

Charlie Calvert's Community Blog — Fri, 12 Jan 2007 11:56:29 GMT

Welcome to the eighteenth issue of Community Convergence. I'm Charlie Calvert, the C# Community PM, and

Lambda Expressions vs. Anonymous Methods, Part Three

Fabulous Adventures In Coding — Fri, 12 Jan 2007 21:05:58 GMT

Last time I said that I would describe a sneaky trick whereby you can get variable type inference out

re: Lambda Expressions vs. Anonymous Methods, Part Two

Richard Smith — Fri, 12 Jan 2007 22:47:02 GMT

You wrote:

"Delegate types are not even structurally equivalent; you can't even assign a variable of type D1 to a variable of type D2."

What's the justification for this? I guess it's to prevent this:

delegate bool FooTester(Foo foo);

delegate bool FooFrobber(Foo foo);

bool IsPrickly(Foo foo) { return true; }

bool MakePrickly(Foo foo) { foo.prickly = true; return true; }

FooTester isPrickly = IsPrickly;

FooFrobber makePrickly = MakePrickly;

// Whoops, meant to pass in isPrickly, not makePrickly.

bool allPrickly = fooColl.All(makePrickly);

But this doesn't really seem to help that much; I'd imagine it's much more common to see either this:

bool allPrickly = fooColl.All(MakePrickly);

or this:

bool allPrickly = fooColl.All(delegate(Foo f) { f.prickly = true; return true; });

Following that argument through, I would allow conversions between delegate types where one can implicitly convert the argument and return types (with covariant return conversions and contravariant argument conversions permitted). Maybe there is potential for harm here, but I'm not seeing it. More likely I've misunderstood something about C#...

re: Lambda Expressions vs. Anonymous Methods, Part Two

Cameron Zwarich — Tue, 06 Feb 2007 10:11:38 GMT

Why is there such a strong insistence in C# on not identifying structurally equivalent delegate types, especially since the introduction of anonymous types makes a completely nominative type system somewhat impossible? Is it just because you don't want to have massive backwards compatibility problems?

If you identified structurally equivalent delegate types, then you could allow anonymous delegate types, as C# requires that all structurally equivalent anonymous types in the same method are identified. This would be a pretty reasonable solution to your conundrum, but perhaps I am missing a subtlety here due to a lack of deep experience with the C# type system. And barring such a jarring change to existing C# features, couldn't you just introduce anonymous delegate types regardless, with the usual anonymous type semantics of divining that the programmer intended all structurally equivalent anonymous delegate types in the same method to be identified?

Learning WPF with BabySmash - Factories, Interfaces, Delegates and Lambdas, oh my!

ASPInsiders — Fri, 13 Jun 2008 10:23:14 GMT

NOTE: If you haven't read the first post in this series, I would encourage you do to that first , or

Learning WPF with BabySmash - Factories, Interfaces, Delegates and Lambdas, oh my!

BabySmash — Thu, 12 Feb 2009 02:53:41 GMT

NOTE: If you haven't read the first post in this series, I would encourage you do to that first