<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 19 May 2018 at 04:34, Chris Angelico <span dir="ltr"><<a href="mailto:rosuav@gmail.com" target="_blank">rosuav@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail-HOEnZb"><div class="gmail-h5">
</div></div>"yield" would have to be a keyword in any context where an expression<br>
is valid. Which, in turn, makes it utterly useless as a function name,<br>
or any other identifier.<br></blockquote><div><br></div><div>Right, I spent a fair bit of time thinking about this in the context of using "given" to introduce postfix assignment expressions, and while it's reasonably straightforward to make it so that keywords that can't start an expression or statement (currently "as", "in", "is", "and", "or") can also be used as names, we don't have that kind of freedom for keywords that can *start* an expression or statement ("async"/"await" relied on some parser tricks that relied on the fact that "async" always needed to be paired with "def" to introduce a coroutine, and "await EXPR" was only permitted inside coroutine definitions).<br><br></div><div>We also run into the problem that even when the compiler can tell the difference, *humans* are still likely to be confused by the potential ambiguity (for the same reason that shadowing builtins is generally considered poor style).<br></div><div><br></div><div>Cheers,<br></div><div>Nick.<br clear="all"></div></div><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>   |   Brisbane, Australia</div>
</div></div>