Future Breaking Changes, Part Two

re: Future Breaking Changes, Part Two

MichaelGiagnocavo — Fri, 31 Aug 2007 17:23:04 GMT

Heck yea they're worth it. Without it, I don't even want to imagine the syntax :\. While you're on the topic, can you explain why method groups don't get the same inferrence?

re: Future Breaking Changes, Part Two

Stuart Ballard — Fri, 31 Aug 2007 18:39:29 GMT

I'm unconvinced about the various "typeless, but convertible to various types" things.

I wouldn't have minded a syntax like:

(string s, int i) => s + i

Situations like this one could be resolved similarly to the way the ternary is:

(string s, int i) => {

if (i > 0) {

return expr1;

} else {

return expr2;

}

With a syntax like that the type of every lambda could be explicit (an "anonymous delegate type" if you like) and inferable completely from its own content without worrying about what type it's being converted to. Then come up with some smart rules about convertability of delegates in general, and you've got a system without any of these issues.

It doesn't feel in the "spirit" of C# to have expressions or entire method bodies whose meaning depends in such a subtle way on the type to which the value is being converted.

Having said that, I still love the feature and can't wait to get to use it in real code, even if I do have nitpicks :)

re: Future Breaking Changes, Part Two

Eric Lippert — Fri, 31 Aug 2007 20:28:19 GMT

Michael: Method groups _do_ get the same inference. Or, at least, very similar inference. Can you clarify the question?

re: Future Breaking Changes, Part Two

Jon Skeet — Fri, 31 Aug 2007 21:23:58 GMT

Eric,

Out of interest are the C# team keeping abreast of the Java language features being proposed?

In particular, I thought you and other readers might be interested in this blog:

http://blogs.sun.com/abuckley/

The two most recent entries talk about compatibility and the cost of new features, which are of course closely related to the topic of this blog post.

I have to say, it's great that both communities are blogging about language design issues. The difficulties involved have been somewhat shrouded in mystery in the past...

Jon

re: Future Breaking Changes, Part Two

MichaelGiagnocavo — Fri, 31 Aug 2007 22:00:40 GMT

For example:

static void executor<T>(Action<T> f) { f(default(T)); }

static void Main(string[] args)

{

executor(Main);

}

Generates error CS0411: The type arguments for method 'Program.executor<T>(System.Action<T>)' cannot be inferred from the usage. Try specifying the type arguments explicitly.

It'd also be nice if method groups could automatically be treated as delegates. The rest of my inference desires are summed up here:

http://www.atrevido.net/blog/2007/08/02/C+Frustration.aspx

re: Future Breaking Changes, Part Two

Eric Lippert — Tue, 04 Sep 2007 18:42:00 GMT

MichaelGiagnocavo: Thanks for clarifying. There is a good reason why we do not do that. I'll leave a comment on your blog explaining why.

Future Breaking Changes, Part Three

Fabulous Adventures In Coding — Fri, 07 Sep 2007 01:22:03 GMT

As I said earlier , we hate causing breaking changes in our product, the C# compiler, because they cause

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

ASPInsiders — Fri, 13 Jun 2008 10:23:11 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:36 GMT

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