The void is invariant

re: The void is invariant

luckylooke — Mon, 29 Jun 2009 23:33:03 GMT

that's one deep post about the type system. I have never analyzed it in so much depth although i run into the problem before with action<int> (btw i allways wandered if int is the most commonly used type ever and i think it is) trying to do the same thing... The compiler yelled at me so I considered aaah void is not a supertype of int me bad, never even thinking about the stack

now i am one thing smarter:)

thanks for that

luke

re: The void is invariant

Pavel Minaev [MSFT] — Mon, 29 Jun 2009 23:34:43 GMT

This seems like an implementation detail. In the end, the actual stack that is used when executing code is native stack, not IL stack - and it seems like CLR itself could insert cleanup calls for cases where a non-void method would be called via a void delegate.

In fact, it seems that it wouldn't even need any cleanup on x86 for most cases, given that in native code the return value is just EAX for all primitives <= sizeof(int) and all reference types, which can be safely ignored. So it would only have to do additional setup for returning value types and such.

Of course, when looked that way, it's not a C# limitation - it's a CLR limitation.

re: The void is invariant

freeborn — Tue, 30 Jun 2009 00:06:46 GMT

why not to translate it as

Action<bool> action = x => DoSomething(x);

re: The void is invariant

Scott — Tue, 30 Jun 2009 00:38:34 GMT

Another reason why the unit approach from ML used in F# is superior to the strange special-case void keyword =)

It would allows syntax like C++'s "void return" too:

void foo() { return; }

void bar() { return foo(); }

Whereas trying the same thing in C# gives error CS0127:

private void Foo()

{

return;

}

private void Bar()

{

return Foo();

}

re: The void is invariant

configurator — Tue, 30 Jun 2009 00:45:47 GMT

Not to nitpick,

Really? -- Eric

but shouldn't "member group" be "method group" in the sentence "When assigning a member group to a delegate type"? Also, in the same sentence you say "selected member" and I think that should be "selected method"

Yes. I make this mistake all the time; if you read back in the blog carefully you'll see that I call out this mistake here and there. The reason is because the specification says "method group" but the structures in the compiler say "member group", and I read the compiler sources more often than I read the spec. The data structures in the compiler can represent both methods and propery accessors, so "member group" is a reasonable name. I also have a bad habit of saying "type variable" when I mean "type parameter" for the same reason. The compiler and the spec were written at the same time; the compiler authors had to guess what the spec authors were going to choose as the jargon, and sometimes they guessed wrong. One of these days I'll clean all those up. -- Eric

re: The void is invariant

CPDaniel — Tue, 30 Jun 2009 01:44:17 GMT

It looks like you meant

Action<void> action = DoSomething;

where you wrote

Action<bool> action = DoSomething;

... as written, the code compiles just fine.

re: The void is invariant

configurator — Tue, 30 Jun 2009 03:00:10 GMT

CPDaniel: I don't have Visual Studio on me to check, but your comment puzzles me. He didn't mean Action<void> because that would mean a method that accepts a void parameter - which is invalid any way. Eric was talking about return value covariance, where the Func<bool, bool> becomes a Action<bool>, returning void instead of a bool.

re: The void is invariant

jMarkP — Tue, 30 Jun 2009 11:58:40 GMT

Fascinating as always :) Do you personally know of any good textbooks on this kind of thing - type systems, lambda calculus-y goodness? (The obvious SICP notwithstanding.) I'd love to flesh out my knowledge more on the theory behind languages and compilers.

"The Little Schemer" uses a fun question-and-answer approach to learning about CS theory via lambdas. But I recommend asking this question on stackoverflow; you'll get a lot higher quality of responses. -- Eric

re: The void is invariant

tb — Tue, 30 Jun 2009 18:21:45 GMT

"Shouldn’t “void” be considered a supertype of all possible types for the purposes of covariant return type conversions from method groups to delegate types?"

I see no reason why it should. It doesn't work for normal delegates, so I can't imagine why it should for Func<T> or Action<T>.

re: The void is invariant

CPDaniel — Tue, 30 Jun 2009 21:15:37 GMT

configurator:

Yes, you're right - I wasn't paying attention! The void return type is implied by the Action<T> generic delegate type.

re: The void is invariant

Leopold Bushkin — Tue, 30 Jun 2009 22:15:41 GMT

An interesting insight into the internals of how the compiler treats delegates and method group conversions to delegates. One question though, couldn't the compiler still allow this by automatically wrapping the method in a dynamically generated lambda, like so:

Action<bool> action = a => DoSomething(b);

Aside from the potential performance implications of the double indirection, is there a non-obvious reason why this could be problematic?

re: The void is invariant

TheCPUWizard — Wed, 01 Jul 2009 03:15:04 GMT

Leopold,

As previously pointed out, it is not just a simple "double indirection". Right in the middle code must exist which cleans up the return value of "DoSomething". When using the technique explicitly, the developer should be aware of this. If the compiler implemented this "automatically" (appearing to be co-variant) then a "secret" overhead would exist.

At least that is why I am glad that the compiler does not do this automatically....

re: The void is invariant

Pavel Minaev [MSFT] — Wed, 01 Jul 2009 04:04:08 GMT

A secret overhead already exists in many places in the JIT - for example, covariance and contravariance of delegate types when interfaces are involved cannot be free - it has to do some pointer shifting and such.

Even C++ has that - compile a code sample with covariant return types of virtual functions with virtual base classes with /FA and see what dances the compiler has to do to make it all work...

re: The void is invariant

configurator — Wed, 01 Jul 2009 09:42:19 GMT

Eric, yes, really. How will I learn without asking these annoying questions all the time? Maybe I misunderstood something and a member group is actually something else? Now you've assured me that I understood your post correctly - and gave me a little insight into the compiler stuff.

Do this member groups represent all properties (as in, a setter and a getter is the same group), or overloaded indexers, or something else that I haven't thought of? (I realize there can be a group with exactly one member and there would always be a group. I'm asking when is there more than one member in the group?)

re: The void is invariant

Daniel Earwicker — Wed, 01 Jul 2009 13:29:20 GMT

Very interesting, but I'd second freeborn's question. If a very simple boilerplate code shape can solve the problem, then the technical problem doesn't seem to explain the language design decision.

But then, if a very simple boilerplate code shape can solve the problem, that's obviously going to push this problem down the list of priorities.

At one point I was dead keen on the possibility that C# (or the CLR) would one day unify Func<void> and Action, making them just synonyms for exactly the same thing. I even tried to work the whole thing out, for my own amusement... but in fact it makes more sense for them to be separate. Action<...> is for things where order of execution is important because there may be side effects. Func<T, ...> is ideally for side-effect free, order-ignorant computations. So it may be better to keep them separate.

Similar to the popular debate over a "ForEach" extension method, which also appealed to me until I read what Eric had to say about it. There is probably some value in making actions and functions "look" different in our code.

re: The void is invariant

Leopold Bushkin — Wed, 01 Jul 2009 16:57:11 GMT

@TheCPUWIzard,

are you suggesting that using a lambda to wrap a function so that it's return value is ignored would cause the stack to not be correctly unwound? I don't believe this to be the case - I've been able to use this approach successfully in real-world code and I have never observed any negative consequences of doing so.

However, if you are suggesting that there is a theoretical performance penalty to using this technique, then I would agree with that.

re: The void is invariant

TheCPUWizard — Wed, 01 Jul 2009 17:24:53 GMT

@Leopold,

I definately did not intend to imply that where is anything "wrong" with using the wrapping technique. It is perfectly safe, valid, etc.

What I am concerned about are implicit operations that may not do exactly what the developer (especially junior to mid-level) expects.

When a construct (such as assigning an integer to a floating point) is extremely common, and the impact is well understood, then "true" implicit features are a great help.

Next comes "explicit implicits" (such as declaring a conversion operation on a class) has control over what happens, and it can be implemented for specific cases where it is justified. These are also a great help and by their very nature have little risk of unexpected effects.

[IMHO] it is when the compiler/language becomes very "liberal" with regard to "inherent implicits" that I see a risk (in terms of developers not truely comprehending shat is going on).

re: The void is invariant

Pavel Minaev [MSFT] — Thu, 02 Jul 2009 21:01:02 GMT

Overall I think the shortest answer why there's no covariance & contravariance for Void<->T can be summed up as: "because Void is not a subtype or supertype of T". One may argue whether _that_ limitation is reasonable or not, but it is what it is.

re: The void is invariant

quetzalcoatl — Fri, 21 Aug 2009 17:20:07 GMT

Eric: "every time we add a new conversion rule to the language we add breaking changes"

Not true. if something would have not compiled, and now it will - this is NOT a breaking change.

Pavel: "This seems like an implementation detail. In the end, the actual stack that is used when executing code is native stack, not IL stack - and it seems like CLR itself could insert cleanup calls for cases where a non-void method would be called via a void delegate."

I 100% agree. I started to write a reply to say this very thing. This is a CLR implementation detail, it is an side effect and limitation, not a the only right way that we all shall be ecstactic that the .net had chosen

freeborn: "why not (..)"

And by this limitation about void (and other nonexistent (co/contra)variances) everyone ends in handwriting sucha stubs like freeborn shown. A few characters about which that Eric is furious at the end of the post. You see, if you not include mechanism that will spit ot all the little methods, people WILL do it by hand, not find another bright solution.

Btw. its really hard to find a brighter solution that Freeborn's, when you have ie. a framework events requesting return-void, and methods that return-bool, methods that ARE used ELSEWHERE in the code, and they must return that bool. What you do? For each such case, you write an adapter that looks like Freeborn's, or, you sculpt a generic that will envelop typical cases..