The red-underlined errors read “embedded statement cannot be a declaration or labeled statement” and the green-underlined warnings read “the variable ‘i’ is assigned but its value is never used.”  You’ve probably seen the warning quite a few times before, but the compiler error really caught me by surprise.  I mean it makes sense that declaring a variable in the one-line body of a control structure is pointless, as it would immediately go out of scope (and usefulness) after declared.  But I thought it odd for the compiler to actually deny such a program statement, as if it put the compiler in an invalid state or maybe it was somehow dangerous.

One thing I do want to point out that appears to be different from the other languages (or at the very least Objective-C) is that the variable declaration is allowed in the switch statement, as illustrated in the image above.

To figure out why this isn’t allowed, I decided to actually look into the C# 3.0 Language Specification to see if there were any comments or explanations regarding this issue.  I ended up finding the C# language grammar in Appendix B.  I was able to parse through the grammar and find this restriction in the grammar itself.  Take a look:

B.2.5 Statements

…

…

You’ll notice that there is the concept of a statement and an embedded-statement; also note that statement is a superset of embedded-statement, adding two other types of statements: labeled-statement and declaration-statement.  If a particular grammar rule requires an embedded-statement, then those two latter types of statements are not allowed in that context.  If we wanted to allow those two statement types, our grammar rule should specify the generic statement category instead.

Also noteworthy is that an embedded-statement can resolve to a block, which includes braces around a statement-list.  A statement-list is one or more statement entities, which would now allow us to use the two statement types excluded from embedded-statement.

Something interesting that is not included in the grammar snippet above, the following statement constructs (and language keywords) require the block statement construct, bypassing the option of a grammar resolution to embedded-statement directly and allowing you to leave off surrounding braces: try, catch, finally, checked, and unchecked.

Almost all of the other statement constructs allow you the option of a one-liner embedded-statement (or which can be resolved into a block), including if, if-else, while, do-while, for, and foreach.  The one surprising exception is the switch construct, which allows for a statement-list after each switch-label.  As a side note, this allows you to put useless braces (via block) around your statement-list (or anywhere inside it) after any of your switch-label statements if you wanted.  But back to the point, these facts explain the existence of (and in one case, lack of) compiler errors regarding embedded statements in the code screenshot near the top.

Now you will know exactly what the compiler means when it gives you the error that an “embedded statement cannot be a declaration or labeled statement.”

Rereading this MSDN article from the former post and reading the Form object’s BeginInvoke method description which I quoted above set me straight and got rid of my blocking UI problem (again).

During this research session, I came across another informative resource when trying to figure out what was meant by potential resource leaks when using BeginInvoke with out later calling EndInvoke.  From reading the article, I gather you can substitute the EndInvoke call with the OneWay attribute on the method being invoked, as long as it has a void return signature and no ref nor out parameters.  Please let me know if my interpretation is wrong.  I added the attribute to my code in the applicable spots and have seen no side effects of doing so.  Here is the article on read mentioning this attribute:

Defensive Event Publishing in .NET – Part I

"Unlike most shells, which accept and return text, Windows PowerShell is built on top of the .NET common language runtime (CLR) and the .NET Framework, and accepts and returns .NET objects. This fundamental change in the environment brings entirely new tools and methods to the management and configuration of Windows.

"Windows PowerShell introduces the concept of a cmdlet (pronounced "command-let"), a simple, single-function command-line tool built into the shell. You can use each cmdlet separately, but their power is realized when you use these simple tools in combination to perform complex tasks. Windows PowerShell includes more than one hundred basic core cmdlets, and you can write your own cmdlets and share them with other users.

"Like many shells, Windows PowerShell gives you access to the file system on the computer. In addition, Windows PowerShell providers enable you to access other data stores, such as the registry and the digital signature certificate stores, as easily as you access the file system."

If you want to know more about PowerShell, I would suggest the following readings:

• Wikipedia - Windows PowerShell
• MSDN - Windows PowerShell Getting Started Guide

Also, James Kovacs from CodeBetter.com has been doing a series of posts on the basics of PowerShell that is a great light introduction to how a developer would find the tool most useful.  Here are two of the starting posts from that series:

• Getting Started with PowerShell - Developer Edition
• PowerShell, Processes, and Piping

"The yield keyword signals to the compiler that the method in which it appears is an iterator block.  The compiler generates a class to implement the behavior that is expressed in the iterator block.  In the iterator block, the yield keyword is used together with the return keyword to provide a value to the enumerator object.  This is the value that is returned, for example, in each loop of a foreach statement.  The yield keyword is also used with break to signal the end of iteration."

You are essentially building an enumerator (or iterator), and with each iteration of your foreach loop in the calling, consuming code, you are executing your method containing the iterator block until it reaches a yield return statement.  At this point, only one item at a time in the collection is returned back to the consuming foreach loop for immediate logic execution by the body of the loop.  On the next iteration of the consuming foreach loop, the method containing the iterator block will be called again and another single item in the collection will be returned for similar logic execution.

This game of execution control Hot Potato has its benefits, in that you can stop the flip-flop of execution control when the music has stopped.  In this analogy, I am comparing the "music stopping" to your code satisfying some logic that makes the rest of your foreach loop iterations unnecessary (perhaps you have found the one item in the collection you were looking for by meeting the sufficient requirements of an if statement).  The benefit is that when you break out of the consuming foreach loop before completing the iterations, you prevent wasteful code execution and memory use.  This feature prevents one piece of code from fully populating a potentially large collection of items, just to have another consuming piece of code iterate partially through the list and then prematurely exit.  Consider the savings especially when adding each item to the collection may be computationally intensive or if each item in the collection is itself a very large data structure.  In the Hot Potato analogy, this would be as if the kids in the circle who didn’t touch the "hot potato" never existed in the game, saving floor space and unnecessary tosses to people you don’t really want to target for humiliating removal from the game.

For good sample code snippets of using the yield keyword, see the links provided above.

I hope to identify situations in the near future where I could benefit from using this C# keyword.  Hopefully then I won’t forget a year down the road from now and then have to re-search the internet for Joshua’s blog post and the MSDN article to remind myself what I already learned.

FOLLOWUP (03/26/09):  So I’m not sure how I missed it, but it took reading a very recent article by Scott Mitchell of 4GuysFromRolla.com to understand the real reason the yield keyword was introduced.  The introduction of this keyword in .NET 2.0 was most helpful in the case of fulfilling the requirements of implementing the IEnumerable interface, which typically required you to create a sub-class that implemented IEnumerator.  In many cases, it allowed you to take about 50 lines of code and turn it into 2 lines of code using the yield keyword.  The introduction of LINQ brought heavy reliance on enumerating using the yield keyword in order to pipeline query operators together.  Scott Mitchell takes you through this whole journey, tying all of the loose ends together to create a complete history of this keyword and how it’s most commonly utilized.  Please visit the following article to get the whole picture:

• An Extensive Examination of LINQ: The Ins and Outs of Query Operators