C# Language Suggestions

[Andrew]

Hello,

I understand that this is a good place to post suggestions
about future changes to the language, and that the
Microsoft developers who develop C# read this newsgroup.
If there is a more appropriate place to post this, please
let me know. So, here are a few things I'd like to see.

1. A way to declare a local variable as being readonly.

2. A way to define static variables that are only
accessible from within a given function, like in C++.
This is a nice form of information hiding, helps put
definitions near their use, and reduces clutter in the
class.
Andrew

[Andrew]

>> (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).

[Jon Skeet]

Andrew <as********@nos pam.onezero.org > wrote:

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.

How exactly would you propose using class variables instead of local
variables? Bear in mind that:

o There may be multiple threads running a single method at a time
o A single thread may have recursively called the same method several
times

Presumably it would be possible to mimic local variables through the
use of ThreadStaticAtt ribute and storing everything within Stacks, etc
- but that's a far cry from the simplicity with which you can mimic
"method-local statics".

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too