Ignoring parentheses

Ignoring parentheses

Rate This
  • Comments 16

Yet another amusing question from StackOverflow: is there a difference between “return something;” and “return (something);” in C#?

In practice, there is no difference.

In theory there could be a difference. There are three interesting points in the C# specification where this could present a problem.

First, conversion of anonymous functions to delegate types and expression trees. Consider the following:

Func<int> F1() { return ()=>1; }
Func<int> F2() { return (()=>1); }

F1 is clearly legal. Is F2? Technically, no. The spec says in section 6.5 that there is a conversion from a lambda expression to a compatible delegate type. Is that a lambda expression? No. It's a parenthesized expression that contains a lambda expression.

The compiler makes a small spec violation here and discards the parenthesis for you.

Second:

int M() { return 1; }
Func<int> F3() { return M; }
Func<int> F4() { return (M); }

F3 is legal. Is F4? No. Section 7.5.3 states that a parenthesized expression may not contain a method group. Again, for your convenience we (accidentally!) violate the specification and allow the conversion.

Third:

enum E { None }
E F5() { return 0; }
E F6() { return (0); }

F5 is legal. Is F6? No. The spec states that there is a conversion from the literal zero to any enumerated type. "(0)" is not the literal zero, it is a parenthesis followed by the literal zero, followed by a parenthesis. We violate the specification here and actually allow any compile time constant expression equal to zero, and not just literal zero.

So in every case, we allow you to get away with it, even though technically doing so is illegal.

  • > The limit on number of template parameters is not directly relevant here

    That's surprising.  I'd have said the upper limit on formal parameters *is* relevant, in a hairsplitting kind of way--and *because* Func and Action are "normal generic delegate types manually declared in System.Core.dll" and not magical.  The framework can only declare a finite number of Action/Func delegates, while the spec allows arbitrarily many formal parameters on a method.  Therefore, an algorithm that maps lambda expressions to pre-existing delegates built into the framework, is provably out of spec.  

    I suppose the algorithm could be tweaked to choose Action/Func when an appropriate match exists, and fail to compile otherwise, but that'd be a surprising kind of compile error, to me at least.  I'm making a generalization, but my sense of the C# compiler philosophy (almost entirely learned here) is to fail to compile if it can detect even a *potential* problem, even if an easily and effective workaround might exist.  

Page 2 of 2 (16 items) 12