10.4. Definite Assignment Algorithm

**10.4.4.23 General rules for expressions with embedded expressions**

Consider the expression `false == x` in the program below. According to 10.4.4.23, the definite assignment state of *v* after this expression is the same as the definite assignment state of *v* after `x`. The definite assignment state of *v* after `x` is the same as the definite assignment state of *v* before `x`. The definite assignment state of *v* before `x` is the same as the definite assignment state of *v* after `false`. And that is "definitely assigned after true expression". That would make this program legal:

``` c#
void M(bool x)
{
int v;
if (false == x) Console.WriteLine(v);
}
```

I don't think that is what is intended.

The root of this problem is text, which appears many places in the specification, of the form

> The definite assignment state of *v* at the beginning of *something* is the same as the definite assignment state at the end of *something else*.

Rather than saying it is "the same" it should say something like

> The definite assignment state of *v* at the beginning of *something* is "definitely assigned" if *v* is definitely assigned at the end of *something else*, otherwise it is "not definitely assigned".

---
**Issues remaining from ECMA-TC49-TG2/spec#413**

> [@gafter] There are other edgier cases missing or not quite right in the spec (e.g. arguments to not-implemented partial methods are not evaluated so do not affect definite assignment; definite assignment behavior of labeled statement not specified; definite assignment state at the end of a block is not specified; the spec makes every local variable definitely assigned after the declaration of another local variable with an initializer).

---
**Issues remaining from ECMA-TC49-TG2/spec#811**

There was an unresolved proposal:

> [@Nigel-Ecma ] For the new added §10.4.4.21 clause "General rules for constant expressions"

> The clause has two examples, both are just code without comments and are not followed by prose, i.e. there is no explanation of these examples.

> **Proposal**: In §11.4.4.21 add some prose or in-code comment explaining why these are examples of the preceding normative text.

Then suggest code for the in-code comment option for one of the examples, the other would be changed similarly:

> [@Nigel-Ecma][@ToshiKurokawa]

>> _[Example:_
>>
>> ```
>> int x;
>> if (true)
>> {
>> Console.WriteLine(x); // error, x is not definitely assigned
>> }
>> else
>> {
>> Console.WriteLine(x); // ok, x is "definitely assigned after false"
>> }
>> ```
>>
>> _end example]_