Inner workings of the IF() function - why aren't expressions evaluated?

Question

Short version

How does the IF() function cause the passed expressions to NOT be evaluated prior to being passed in as parameters?

Detailed version

I am part of a standards committee, and a discussion was initiated which, in general, is trying to ban the use of the IIF() function. The general consensus is that if you want to do a short line-length assignment IF() is okay. And if you for some reason want to evaluate two expressions, don't try to accomplish that all on one line, explicitly and purposefully evaluate the expressions on seperate lines, then do an IF() call with the results in the If True and If Else parameters.

I'm asserting that before a Function(param1, expression) is stepped into, any expressions are evaluated. Then, their evaluated value is passed as a parameter.

That being asserted, this makes sense:

Sub Main()
    Dim intTest As Integer = 0
    Dim blnResult As Boolean = IIf(2 = 2, Integer.TryParse("3", intTest), Integer.TryParse("4", intTest))
    'intTest = 4
End Sub

• As expected, blnResult is True.
• Because the conditional of the IIF() function is True, the value of the expression in the "If True" parameter is the resulting assignment.
• But BOTH the If True AND If Else expressions were evaluated (in written order) prior to even stepping into the IIF() function, so intTest became 4.
• As far as I'm concerned, that is programatically expected, but not the results desired.

On the reverse side of the coin, we have this:

Sub Main()
    Dim intTest As Integer = 0
    Dim blnResult As Boolean = If(2 = 2, Integer.TryParse("3", intTest), Integer.TryParse("4", intTest))
    'intTest = 3
End Sub

As the inverse of the previous issue, we now have:

• As expected, blnResult is True.
• Because the conditional of the IF() function is True, the value of the expression in the "If True" parameter is the resulting assignment.
• But ONLY the If True (in this case) is evaluated, so intTest became 3.
• As far as I'm concerned, that is the results desired, but not programatically expected.

I'd like to see a custom function that does the same thing as IF().

Answer 1

Your confusion stems from a misapprehension:

Inner Workings of the IF() Function

How does the IF() Function

the conditional of the IF() Function

I'd like to see a custom function that does the same thing as IF()

But IF() is not a function.

The language specification for VB.NET (freely available for download) has this to say about If. I quote the 11.0 version; emphases as mine, and note that the apparent error in the example is a direct quote!:

11.22 Conditional Expressions

A conditional If expression tests an expression and returns a value. Unlike the IIF runtime function, however, a conditional expression only evaluates its operands if necessary. Thus, for example, the expression If(c Is Nothing, c.Name, "Unknown") will not throw an exception if the value of c is Nothing.

Note the difference: If is an expression, whereas IIf is a function. Like any other function, IIf obeys the usual parameter evaluation rules. But If, being an expression, doesn't have to.

You wouldn't expect

If <condition> Then
    ' Do this
Else
    ' Do that
End If

to do both this and that; similarly, you shouldn't expect If to evaluate both parts.

You're not going to be able to readily make a function that does this, any more than you'd be able to (say) make a function that does what Using does - it's part of the language.

Answer 2

IF() is treated as a special case by the compiler. You can't make your own function that works exactly the same way without making your own compiler. You could use delegates or lambda expressions to similar effect, though.

Answer 3

You're basically describing short-circuit evaluation.

I don't see the issue you describe as fundamentally different than the difference between And and AndAlso. If you're going to ban IIF, you're also going to have to ban And, since it doesn't short-circuit either (both operands are always evaluated).

Banning language constructs that do not short circuit might make more sense if you also require your functions to never have side-effects. If you allow side effects in your functions, those side effects will not occur if they are in the short-circuited part of a function evaluation.

Further Reading
Why would a language NOT use Short-circuit evaluation?

Answer 4

VB.NET has an operator that does double duty as both the ternary and null coalescence operators. This operator is If. It also has a function, IIF, which takes three parameters.

These are two entirely different things. The IIF function is just that, a function, you could write your own that does the exact same thing. It should be avoided, it became obsolete the moment the operator was introduced.

Now, the IF operator is quite handy, and allows doing things that would have been extremely difficult to even approximate, and impossible to exactly duplicate, before lambdas were introduced (you still can't exactly duplicate it, but you could get a similar effect). There is no reason to avoid it, it behaves as expected, so even if you don't know about it, it doesn't surprise -- so it is not a danger for junior programmers.

Both functions of the If operator are basically short circuiting calculations, and that's a good thing.

If the standard you are working on is for using VB.NET, then it should be recommended. If it's for a new language, I recommend both operators as being useful additions to readable and understandable programs (you might want to make them a bit more distinct).

PS: You say that IIF behaves as expected, I would deny that and change your example a bit:

 Dim input as String = "Junior"
 Dim parsed as Integer
 parsed = IIF(IsNumeric(parsed), CInt(input), -1)

Throw that at someone not familiar with the language and they naturally expect parsed to be -1. Which is not what happens, instead you get an invalid cast exception. http://ideone.com/JfbFwi

I have fixed bugs exactly like the above.

Answer 5

Technical answer:

We all know the If() function is "the ternary operator for VB.NET", whereas IIF() is a function (though still technically ternary). But saying If() is "the ternary operator" doesn't mean we know what's going on behind the scenes. Well, it turns out literally what's going on behind the scenes is that the If() function is evaluated as an expression which is interpreted by Common Intermediate Language (CIL) as a C-esque ternary operator, as displayed in the CIL below:

bool arg_20_0 = true ? int.TryParse("3", out intTest) : int.TryParse("4", out intTest);

Description:

As part of the previous answers, it was brought up that the compiler probably interprets the IF() function as an expression instead of IF() actually being a regular function. It is partially true.

It was also brought up that if you were to ban IIF(), you'd also ban things like And and Or in place for short-circuit-only code. That was much closer to the real answer than I expected at first.

As a simple test, to which I am emberrassed I didn't try first, since I have ILSpy right on my desktop and use it all the time, I found that the real answer was the very first comment... MichaelT asked:

Just verifying, the IFF(A,B,C) is equivalent to A?B:C in a C-esque language?

LAWL!!! This is the CIL code:

bool arg_20_0 = true ? int.TryParse("3", out intTest) : int.TryParse("4", out intTest);

So it's partially true that IF() is not a real function, but it's evaluated in the CIL before going to the compiler, so it's not a function of creating your own compiler. I'll give credit to MichaelT if he posts this as his answer, he was 100% correct without even knowing it.

Edit (addition):

As stated in the comment, I said I'd post the CIL for IIF(). This is it...

bool blnResult = Conversions.ToBoolean(Interaction.IIf(true, int.TryParse("3", out intTest), int.TryParse("4", out intTest)));

Which is exactly as expected, because IIF is an actual function, so of course the parameters are evaluated before stepping into the function. I also sort of knew it was in the Interaction namespace. But like I said, IIF() isn't the mystery, it's understood, but just not the intended results.