cody said:
You should not overvalue code breaking - programmers who was really stupid
enough to use yield as identifier can quickly change that in their code
(That yield would be used as identifier later was known a long time). The
change will also *not* break already compiledd assemblies. In other
languages including C++ there was lots of keywords added, years after the
original specification of the language and there was not problem.
But how long, some code may be 2 or 3 years old by this point, I didn't hear
about yield likely being an identifier until about a year ago, maybe a
little longer. I don't know if some of my own code would break, not to
mention however millions of lines were written before anyone had any clue
that iterators would be a C# feature with the .NET 2.0 framework.
And as I recall, C\C++ reserved all names starting with __ or something to
that effect, so it was your fault if you screwed up, they told you
beforehand what not to use. I don't want to see C# take the approach of
prefixing keywords with __ (or any other sequence) just to maintain the
ability to add keywords. Add onto that the utter complexity of a C++ and a
C++ compiler, and I don't think that argument is worth much. C++ is maybe
too complex, has too many keywords, it does have an effect on C++ itself, if
not with the compiler then with the language itself, a concious decision to
avoid bloating the language is very important for C#.
But I know lots of people (even in a few years) will hate this unneccessary
verbose and annoying syntax only because in the *very* early days somebody
decided that yield *could* *eventually* break some code written in the early
days of c#.
I doubt it, its not a big deal and it maintains a simplier grammer, plus its
clearer, reserving a keyword really should be a last resort. If you are too
lazy to type yield return one time per iterator(twice maybe, I doubt it
would be much more than that), you really shouldn't be programming. Its
really not a big deal. However, even if yield could have been used as a
contextual statement, it would have confused people when used with yield
break, which I argue about below.
However, "yield return" or not, I don't understand why "yield break" is
neccessary as a simple "return" would do it perfectly. The meaning of return
is: The method ends here. You should preserve that..
The meaning of return is NOT the method ends here, it means this CODE PATH
in this method ends here, here is the value you were interested in, or
atleast as close as I could get, it inessence returns a value from the
method, a return is not needed to end a method(however the langauge and
probably the runtime enforces it when there is a return type specified).
Blank returns are valid only in void methods where there is no return value
but in that case it is a syntatic nicety that makes logical sense, no value
to return, so return can stand alone. An iterator, on the other hande, does
have a return value, an enumerator or enumerable interface. A empty return
statement doesn't make sense, yield break does.
It keeps the complexity of the language grammer from growing to high, it
doesn't require changing the rules of return, which would be, by far, the
worst choice they could make.
--
cody
[Freeware, Games and Humor]
www.deutronium.de.vu ||
www.deutronium.tk
Eric Gunnerson said:
We had originally used "yield" by itself, but unfortunately, that would
require us to add a new keyword to the language, which has the potential to
break current code. By using "yield return", we don't have to do this.
--
Eric Gunnerson
be
no "yield"
as
)
).