(local readonly discussion)
I don't have any real comments here.
So What's the next step?
I don't agree. Local variables and class fields are very different beasts,
with locals being associated with the function and instance ones associated
with the instace (somehow that seems like a tautology).
Or, to put it another way, you can get the identical effect by using a
class-level const/readonly as you could over one declared in the function.
It would mean the same thing. It's really just a question of where you get
to declare them.
(This part of the discussion was about function-static
variables, not "const/readonly" -- I guess you
meant "static" here instead of "const/readonly".)
As I understood it, the argument that was presented
against having function-static variables was: if some
thing X already can be done at the class level, then one
doesn't get anything new by having X be done locally in a
function. My point was that there is something wrong with
this argument because if one takes X="variable" then the
argument is claiming that nothing new is obtained by
having local variables (since one could use class fields
instead of local variables), and yet C# has local
variables.
Information hiding is the reason that I'm suggesting this
feature.
That would be the same as if it was declared as static to the class. My
point is that it's easier if all the class-level variables are centralized
rather than being spread out in various methods.
As I discussed, I do not agree that the case of a thread-
safe application is easier without function-static
variables, and I have not heard any other cases. So I
don't understand what it is that's easier if function-
static doesn't exist. My personal preference would be to
localize the information to get information hiding, not to
put all the information at a level where it's accessible
to entities that have no business accessing it.
The complexity argument is at least as important as this one, however. Since
you can get the same effect with a class-level static, you don't need to
have method-level statics, and we generally try not to add a feature that
duplicates something that's already there.
I am happy that C# has gone in the direction of trying to
keep things simple. That is one of the things I like
about the language, and I would not want things to be
otherwise. The new capability that function-static would
add is a form of information hiding that is not present
with class-static variables. Simplicity is one design
criterion, and information hiding is another criterion,
and information hiding has precedent in C#, e.g., there
are no global variables, classes can have private and
protected variables, functions can have local variables,
and "for" and "foreach" variable scope is limited to the
loop. These things aren't functionally necessary, except
for local variables (which also provide information
hiding).