<div dir="ltr"><div dir="ltr">Den ons 20 jan. 2021 kl 14:58 skrev Nalin Ranjan <<a href="mailto:ranjanified@gmail.com">ranjanified@gmail.com</a>>:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>As I could have a name whose first occurrence happens to be on line number 100, and all subsequent occurrences annotated with ^ in a defensive style. So far so good.Tomorrow I could embark on "Refactoring" fleet, and add some new code to the function around line 30-50, and endup naming one of my new variables to be the same as the one on line number 100. Situation, re-emerged. I need to go and attend these variables to deal with the situation.</div></div></blockquote><div><br></div><div>The whole point of the annotations is that previously, if you did what you described, your new code would be accepted without a word from the compiler, but would crash on line 100 when the previous first assignment has turned into an equality assertion. With this EEP and the warnings enabled, the compiler would tell you that your code on line 100 is now an unannotated use of a variable bound around line 30. You would have to change your code, yes, but you would have had to do so anyway because it was broken. The only question is whether you'd like to know about this at compile time or later in testing or in production.</div><div><br></div><div>    /Richard</div><div><br></div></div></div>