Static Method Variables

[chuck-flowers]

I think that it would be a good idea to allow for static variables that are scope to a specific method. We often need variables that remain unchanged from one method to another. The only way to do this is to make them static variables that are scoped to the whole class. Often though these variables may only need to be scoped to a specific method. My suggestion would allow for the same behavior currently afforded by class scoped static variables, but limiting their accessibility to a single method.

Before:

public class Foo
{
    public static int counter = 0;

    public int IncAndGetCount()
    {
        //Only method that should be able to access counter
        return ++counter;
    }

    public int Square(int i)
    {
        //Has access to counter even though it's not desired
        return i * i;
    }
}

After:

public class Foo
{
    public int IncAndGetCount()
    {
        //Only this method can access counter and its state is persisted from call to call
        static int counter = 0;
        return ++counter;
    }

    public int Square(int i)
    {
        //Attempting to access counter would result in compile error
        return i * i;
    }
}

[Joe4evr]

Dupe of #832.

[MkazemAkhgary]

first of all, if counter is only desired to be accessed by single method, why do you make it public?

once you make it private, it will be implementation detail, how you would use counter internally does not matter for user.

that's whole purpose of private access modifier.

[chuck-flowers]

Yeah I should have made counter private in this example but the purpose of the feature request isn't to protect it from external access its to protect it from the Square function accessing it from within the same class.

[bondsbw]

@MkazemAkhgary

once you make it private, it will be implementation detail, how you would use counter internally does not matter for user.

This is true for users of the class. But also consider the future developers of the class (including yourself) who may not understand or remember the original intent that the field shouldn't be accessed outside of that method.

This follows the same reasoning for local methods.

[Joe4evr]

Either way, can you move discussion to the other thread? Better than having two separate discussions of the exact same thing.

[MkazemAkhgary]

@bondsbw ok, so what about instance fields that should be limited to single method? Certainly, non static variables inside method are local variables and have limited lifetime. What this proposal is asking for is misleading.

I want a feature to limit instance field to single method, why wouldn't that be as valuable as this proposal? Not to mention excessive use of static fields is not a good practice.

[MkazemAkhgary]

who may not understand or remember the original intent that the field shouldn't be accessed outside of that method.

Thats why i always comment code that i write, especially if its tricky, if you write fragile code that can break easy you should consider rewrite your code with better design. I encourage you to write more understandable code.

If its not possible at the moment, for any reason, due to lack of time or knowledge, then comment carefully and be detailed.

[bondsbw]

if you write fragile code that can break easy you should consider rewrite your code with better design

And with a feature like this, I would be able to.

[jnm2]

Yes, please close and continue at the existing conversation.

[MkazemAkhgary]

@jnm2 are you being serious?

look at the following

public int IncAndGetCount()
{
    static int counter = 0; // counter is set to 0 every time...
    return ++counter;
}

You are setting counter to zero at every increment. This is itself misleading, both variable life time and how its declared and assigned. what would happen if you have this?

public int IncAndGetCount()
{
    DoSomethingElse();
    static int counter = 0; // should counter be set to 0? but its a field declaration, what is going on?
    return ++counter;
}

does this even make sense?

You should know that local variables are VERY different than fields. and they must be declared in different blocks, not in same block, else they will conflict with each other.

The reason property scoped variables are well accepted is because properties alongside getter and setter have their own block so a property scoped field can be declared in meaningful way.

public int Prop
{
     int x; // this is no different than field, only scoped to Prop.
     static int y; // be it static or not, its a field 
     get { return x; }
     set { x = value; }
}

Give me one reason that method scoped field (and worse than that, only static fields) with this proposal syntax is not misleading.

Or ill commit suicide 🗡 (just kidding)

If you insist on having method scoped fields, (not local variables) I suggest this syntax.

public class Foo
{
    { 
        int x; // x is field, that can only be accessed in this block.
        public void CanSeeX() 
        {
        }
        public void CanSeeXToo()
        {
        }
    }

    public void CantSeeX() 
    { 
    }
}

[yaakov-h]

@MkazemAkhgary Then create a formal counter-proposal.

[jnm2]

Yes, please close and continue at the existing conversation.

@jnm2 are you being serious?

@MkazemAkhgary I don't understand why you have a problem with moving the conversation to the previous issue because both OPs ask for the exact same syntax with the exact same behavior. I didn't say you were wrong, only that you were talking in the wrong place.

does this even make sense?

You should know that local variables are VERY different than fields. and they must be declared in different blocks, not in same block, else they will conflict with each other.

Do I know the difference between fields and locals? Hmm, that's a hard one... Nope, I don't think I've ever learned that in the 14 years I've been playing with .NET languages. ;-)

More seriously:

• It's well understood; VB.NET does this
• I dislike the use of the static keyword for instance methods and want it to be instance.

[iam3yal]

@MkazemAkhgary

To make discussions more manageable let's try and follow the guidelines:

Stick to the topic of the issue title. If a comment is tangential, start a new issue and link back.
If a comment goes into detail on a subtopic, also consider starting a new issue and linking back.

But just to address one of your points:

You should know that local variables are VERY different than fields. and they must be declared in different blocks, not in same block, else they will conflict with each other.

This proposal isn't about changing semantics but to add a syntactic sugar so in this sense it's definitely possible to introduce a syntax that allows people to declare static variables that are only scoped to the place they are used.

Now, you can't define a block in a class so if you want to address the same issue in a different/cumbersome way, again, feel free to create a new issue about it.

Finally, if the design team followed your logic I really doubt local functions would have seen the light of day. :)

[iam3yal]

@chuck-flowers You should really close it, we don't need multiple issues on the same topic.

[MkazemAkhgary]

I agree with closing this topic, but what this proposal suggests, is not exactly equal to #832

if you look at #832 you will see that original poster only proposed usage for expressions, not locals. but then someone underneath of it, suggested static locals.

I think this misconception is because of proposal title "Static Variables", but it should be "Static initialization" or "static expressions"

[jnm2]

@MkazemAkhgary #832 begins,

Originally proposed at dotnet/roslyn#49, as it exists in VB,

string[] M(string str) {
  static var dot = new [] { '.' };
  return str.Split(dot);
}

That's proposing usage of static on a local as it exists in VB.

https://docs.microsoft.com/en-us/dotnet/visual-basic/language-reference/modifiers/static#rules begins:

• Declaration Context. You can use Static only on local variables. This means the declaration context for a Static variable must be a procedure or a block in a procedure, and it cannot be a source file, namespace, class, structure, or module.

Meaning, #832 starts off asking very precisely for static method variables.

[AustinBryan]

There is a way to use static fields in C#, and it's very clever.

public Func<int> Increment = new Func<Func<int>>(() =>
{
    var num = 0;
    return () => num++;
}).Invoke();

...

var zero = Increment();
var one = Increment();

It's just a complete pain to type.

Edit: It's also probably not good on performance due to the two delegates, but it's there if you really need it.

[yaakov-h]

@AustinBryan I would hope that the compiler could generate code that doesn't require the allocation of two delegate objects.

[NetMage]

@AustinBryan Nice - that let me create a FlipFlop method (Perl ..) that holds state between calls, unique to each caller.