Discussion: static variables

[alrz]

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

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

---

Alternatively we could use static keyword on the expression that we want to cache,

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

Open question: should this turn to a class-level initializer or it should be initialized lazily as in VB?
Open question: would it make sense to generate a non-static field for a cached value?

Possible translations for the following:

object O => static new object();

->

// eager + static field
static object o = new object();
object O => o;

// eager + instance field
object o = new object();
object O => o;

// lazy + static field (similar to VB except for thread-safety)
static object o;
object O => o ?? (o = new object());

// lazy + instance field
object o;
object O => o ?? (o = new object());

plus thread safe variants (note: for value types we should probably use a boolean for lazy initialization.)

Open question: would it worth it to use different keywords to specify a particular translation?

[tuespetre]

I found myself wanting a static keyword for inline expressions this week. This would be great to have.

[franzalex]

Coming from a VB6 & VB.NET background, this is one thing I miss a lot even after over 7 years of programming with C#.

I strongly believe that this is a must-have!

[franzalex]

To address your questions:

Open question: should this turn to a class-level initializer or it should be initialized lazily as in VB?

The VB.NET implementation does not initialize the value until the first time it is used (in the method in which it is located). Doing the same thing in C# will defer potentially expensive initializations until when it is really needed.

Open question: would it make sense to generate a non-static field for a cached value?

Drawing again from the VB.NET implementation, I'd say it depends on where the variable is created.
If it is created in a static method (equivalent to a Shared method in VB.NET), then, the variable ought to be implemented as a static field in order to keep it in scope and preserve its value whenever and however the method that relies on it is called.
If, on the other hand, it is created in an instance method, then the variable ought to be implemented as a non-static field in order to ensure the per-instance integrity if two instances of a class initialize it to different values.

Open question: would it worth it to use different keywords to specify a particular translation?

I'm not really sure of what you mean here. I'll just state that the VB.NET version doesn't allow the keyword to be combined with ReadOnly, Shadows or Shared (readonly, new or static respectively).

It makes sense to disallow combining it with new (VB.NET Shadows) as regular variables tend to have this restriction anyway. Likewise, a person who wants to have a static variable will usually create one with the static keyword anyway. What is really up for discussion is the readonly modifier. I think it is unnecessary to put in that restriction. However, having it in place ends up saving you from yourself if you 'accidentally' try to assign to the variable after it has been initialized.

---

EDIT

For cross-reference, here is a link to the documentation on the Static keyword.

[Joe4evr]

Open question: would it make sense to generate a non-static field for a cached value?
Open question: would it worth it to use different keywords to specify a particular translation?

I would say the following:

• Lazy init pretty much always
• Always in a thread-safe manner
• In a static method: Lift to a static field
• In an instance method: Lift to an instance field
  • Compiler is free to optimize to a static field if it can determine that all data written into the variable is static and wouldn't affect the rest of the program*
• (Maybe) Combine with readonly: Can only assign once, but may be not an actual readonly field
  • Compiler should optimize to a real readonly field if possible by lifting the assignment to either a field initializer, or (if dependent on other fields) into the constructor(s) (would become eager init)

*This rule could be omitted altogether with some alternative syntax I propose at the bottom of this post.

Examples:

public class C
{
    public static string[] M1(string str)
    {
        //static method: lifts to static field
        static var splitchar = new [] { External.GetRandomChar() };
        return str.Split(splitchar);
    }

    public string[] M2(string str)
    {
        //instance method: lifts to instance field
        static var splitchar = new [] { External.GetRandomChar() };
        return str.Split(splitchar);
    }

    public string[] M3(string str)
    {
        //data is statically known: may be lifted to static field
        static var splitchar = new [] { '.' };
        return str.Split(splitchar);
    }

    public string[] M4(string str)
    {
        //lifts to non-readonly instance field, but makes next line illegal
        static readonly var splitchar = new [] { External.GetRandomChar() };
        splitchar = new [] { External.GetRandomChar() }; //ERROR
        return str.Split(splitchar);
    }
    
    private readonly ICharGenerator _generator;
    
    public C(ICharGenerator generator)
    {
        _generator = generator;
        //{A}
    }

    public string[] M5(string str)
    {
        //lifts to readonly instance field, assignment is placed in ctor on line marked with {A}
        static readonly var splitchar = new [] { _generator.GetRandomChar() };
        return str.Split(splitchar);
    }

    public string[] M6(string str)
    {
        //lifts to readonly field, potentially static, assignment is a field initializer
        static readonly var splitchar = new [] { ':' };
        return str.Split(splitchar);
    }
}

Open question: Syntax?

I'm not sold on what's proposed here. It seems to me like the variable is constantly re-assigned every time the method runs, which only makes it look like the very problem it's trying to solve.

Possible alternative:

public string[] M(string str)
    static var splitchar = new [] { External.GetRandomChar() }
{
    return str.Split(splitchar);
}

I think this syntax neatly represents the "in-between" nature of these variables. They're really a field, declared outside of the method, but they're only accessible inside the method. A lot less mental gymnastics, in my opinion.

Open question: Are we married to the keyword static?

It would be symmetrical with VB.NET, but it may overload the static keyword too much for C#. If someone new saw some code with this feature, it would be hard for them to Google what it means in that context since there's already 15+ years of documentation on c# static keyword. (VB doesn't have this problem since that uses Shared for static members and Static for specifically this feature.)

Continuing with the above suggested syntax alternative, a new keyword could be introduced instead.
* cache/cached
* lifted
* something else?

Bonus: Would allow to explicitly define instance/static scoping rather than hoping the compiler make the optimization for you.

EDIT: After a little bit of thought, with that proposed syntax, why even need a keyword? You should just be able to move an existing field declaration (without access modifiers) to right in front of a method body to make it only accessible in that method. Or the other way around if you want it to be a higher accessible field again.

public string[] M1(string str)
    //we're still going to get 'var' for fields, aren't we? let's just pretend we already have that
    var splitchar = new [] { External.GetRandomChar() } //instance field
{
    return str.Split(splitchar);
}

public string[] M2(string str)
    var splitchar = new [] { '.' } //force instance field, even if it could be static, IDE can suggest to make it static
{
    return str.Split(splitchar);
}

public string[] M3(string str)
    static var splitchar = new [] { External.GetRandomChar() } //force static field
{
    return str.Split(splitchar);
}

public string[] M4(string str)
    static var splitchar = new [] { _generator.GetRandomChar() }; //error CS0120
{
    return str.Split(splitchar);
}

Now the thing left on my mind is "Do we need the semi-colon?"

[jnm2]

I'd be happier with an instance contextual keyword. void Foo() { static int scopedInstanceField... } feels wrong to me.

[franzalex]

In general, I think @Joe4evr's suggestion is in line with mine with the only difference being about the combination with the readonly modifier:

(Maybe) Combine with readonly: Can only assign once, but may be not an actual readonly field

Thinking it through once again, I can possibly see why we may want to allow combining with the readonly modifier. If that VB.NET restriction is not to be applied to the C# equivalent, however, I would like to know one thing:

Does applying a readonly modifier cause the compiler to optimize the variable in any way?

I feel like putting a readonly modifier on a variable whose scope is limited to a specific method is not really necessary. This is especially so since one cannot apply a readonly modifier to a variable created in a method. Should one want a cached readonly¹ variable, the person can go ahead to create a class-level variable that serves the purpose better as that modifier in its current state isn't allowed inside a method.

Note that I am not against allowing for a cached readonly field. I am only trying to let us have a more pointed discussion on this particular aspect before anything concrete is decided upon.

‾‾‾‾‾‾
¹ I prefer the cached keyword be used when instantiating such a variable as is being discussed in this thread.

[Joe4evr]

I feel like putting a readonly modifier on a variable whose scope is limited to a specific method is not really necessary. This is especially so since one cannot apply a readonly modifier to a variable created in a method.

It will be when #188 becomes a reality.

[franzalex]

Sorry, I didn't know that such an idea had been proposed. In that case, I think your suggestion can pass without need for any further discussion.

[Thaina]

Miss this since I was using PoC

[franzalex]

@Joe4evr: From a readability standpoint, I find your new syntax quite difficult to comprehend. How do you suppose multiple static variables would be created? One per line? using a delimiter (which one)? Most importantly, wouldn't your new syntax be too much of a breaking change? I strongly believe that the way to go on this is to simply introduce a new keyword or adapt an existing one for use in this situation.

[ghost]

I would love to have this one in the language. The keyword should be "static". Here's the analogy. One can declare a class level "string foo;", and foo is available to the whole class. If "string foo;" is declared inside of a function, it is only accessible in the function. At the class level, one can declare "static string foo;"-- it is a static variable, but it is only accessible inside the class. In a function, you should be able to declare "static string foo;". It is statically scoped, but it can only be accessed from inside the function.

This language tool is great for implementing singleton patterns. The Instance() function would declare "static MyClass _instance = new MyClass();" in the function itself and return it. This prevents others methods of the class from using _instance instead of Instance(). Statically typed variables are dangerous. Keeping all usage of a static method in one small function adds greatly to code clarity.

[scalablecory]

I can see this replacing a lot of Lazy class usage, which would be nice.

[TheUnlocked]

While I see the benefit of using static for caching, I believe that it certainly has uses beyond just caching values. I think that the very first example of static within a method should be added, though I don't necessarily oppose also adding the in-line syntax.

[alrz]

This is similar to local functions, you can bring statics closer to their usage with a scoped name. I mentioned inline syntax to explore alternatives, that's not necessarily a "better" way to do this.

[miyu]

Static locals are nice for declaring reusable (across calls) method-scoped variables that can't be consts.
Here are some example use-cases:

1. Runtime-generated lookup tables for equations. These equations are completely meaningless and magical outside of their code context.

void HypotheticalFunction1(x) {
    // 10 LOC of stuff, introduces int y which hypothetically goes from [0, 10)

    // Nonoptimized:
    return SomeExpensiveFunction(y); // equation might even be in-line and depend on above statics

    // Optimized:
    static var lut = Range(0, 10).Map(SomeExpensiveFunction);
    return lut[y];
}

2. Reusing object instances (i.e. List) across calls to avoid allocs (thread-local).

void HypotheticalFunction2(x) {
    // Unoptimized
    var store = new List<T>();

    // Optimized
    [ThreadStatic] static List<T> storeTls;
    var store = storeTls ?? (storeTls = new List<T>()); // avoids per-call alloc

    // 20 LOC of work

    // Optimized
    store.Clear();
}

Imagine a class with 10 of the (2)-like functions. The scope gets polluted really quickly. To avoid naming conflicts, I name statics "HypotheticalFunction1_lut" or "tlsHypotheticalFunction2_store"... this is really gross. This is incredibly common for me - I'll have a function that allocates 10 collections of different types. I'll want to reuse 10 collections across calls. Guess what? Now I have 10 class-scoped statics. 😢

3. Workaround for inability to use const (i.e. with Fix64 from the fixed-precision arithmetic FixedMath.NET library).

Fix64 HypotheticalFunction3(x) {
    // 10 LOC of work

    static var weight = (Fix64)0.1; // currently can't be const, so computed each time
    static var weightSquared = weight * weight;
    static var invPi = (Fix64)(1.0 / Math.Pi);
    static var one = (Fix64)1;
    var temp = weightSquared * (one - F(x * invPi));

    // 10 LOC of work
}

My 3rd case would probably be better fixed with language support for constexpr functions. In any case, note how fluid changing from var to static var is. For this reason, I'm against forcing static locals to be placed immediately after the method signature. Note that in none of these use-cases is static var being used in a meaningfully stateful way.

[CyrusNajmabadi]

Note: any design here would have to establish the expected behavior of what a static local means in a generic method. I would assume it would be the same as a generic type, and each distinct instantiation would get its own storage location. This makes a static local not akin to a field in the containing type, but rather a field inside a nested type which has the same generic type args as the method it is accessed from. in other words:

void M<X, Y>(int i)
{
    static int static_local = ...;
}

would be the same as:

void M<X, Y>(int i)
{
    StaticLocals<X, Y>.mangled_name_static_local = 1;
}

private class StaticLocals<T1, T2>
{
     // ... 
}

(potentially with some concept of init-once or not).

[TahirAhmadov]

I hope you don't mind - I added the generic stuff to my previous post.

[jrmoreno1]

@CyrusNajmabadi

Note: any design here would have to establish the expected behavior of what a static local means in a generic method.

VB.net behavior is to forbid it - https://docs.microsoft.com/en-us/dotnet/visual-basic/misc/bc32068

[TahirAhmadov]

VB.net behavior is to forbid it - https://docs.microsoft.com/en-us/dotnet/visual-basic/misc/bc32068

2 takeaways here: we shouldn't use VB (or VB.NET) as a source to identically copy and paste from, when designing a language feature in C# (or in any other new language); and that documentation is page is a bit wrong - my private nested static class solution works fine within the constraints of every version of .NET going back to version 2.

[jrmoreno1]

VB's version existed prior to .net so it's not at all strange that it is missing some generic flourishes, if MS was accepting PR's for VB I would think a PR that fixed that would at least be considered. What do you mean by the page is wrong and "my private nested static class solution works fine"? The page says that you can't use Static variables in a method with a direct generic constraint, although you can use them within a method in a class that has a generic constraint, aka M(x as T) can have Static variables, but M(of T)(x as T) can't.

[TahirAhmadov]

What do you mean by the page is wrong and "my private nested static class solution works fine"? The page says that you can't use Shared variables in a method with a direct generic constraint, although you can use them within a method in a class that has a generic constraint, aka M(x as T) can have Shared variables, but M(of T)(x as T) can't.

Imagine this:

class Class<T1>
{
  void Foo()
  {
    static int x; // what VB.NET does is just move this static to the class - it's basically just name scoping
  }
  static int Foo_x; // it's compiled to this behind the scenes

  void Bar<T2>()
  {
    static int x; // here, VB.NET decided to prohibit this, because if it were to...
  }
  static int Bar_x; // compile it to this behind the scenes, it would be inconsistent - does Bar_x belong to Bar<int>() or Bar<string>()?
  static class Bar_Statics<T2>
  {
    static int x; // which is why I suggested this - a special class is created which mimics generics of the method
  }
}

And that last part - my proposed solution - has been available in .NET going back to version 2, with the introduction of generics. That page says "Visual Basic and the .NET Framework do not currently support any combination of static variables and generic procedures." - while it's true that VB doesn't support it, .NET Framework does and (basically) always has done, which is why I said it's an incorrect statement.

[TahirAhmadov]

Another very important and helpful use case: anonymous types and LINQ expressions. Together with partial generic arguments, it makes the following possible. This was inspired by this discussion 5381.

void Test(Expression<Func<int, bool>> predicate) {}
void Foo()
{
  // the following isn't about anonymous types and doesn't need partial generics
  static readonly Expression<Func<int, bool>> isOdd = x => x % 2 == 0;
  Test(isOdd);

  bool flag = true;
  static readonly Expression<Func<int, bool>> isOddOrEven = x => x % 2 == 0 ^ flag; // ERROR: static field cannot reference transient method local

  // the following also needs partial generics
  static readonly Expression<Func<Person, _>> selector = x => new { FullName = x.FirstName + " " + x.LastName };
  var parties = this._personsQuery.Select(selector).ToList();
}

Also in a separate exchange with @HaloFour, he suggested a new raise accessor for events:

  public event EventHandler Event
  {
    static int staticField; 
    instance EventHandler v; 
    add { v += value; ++staticField; } remove { v -= value; --staticField; }
    raise { v?.Invole(sender, e); } // basing on delegate type, the parameters are created implicitly, using the names specified by delegate type
  }

Another minor details: in overloaded methods scenario, static locals will need a new class for each overload. Basically each method, regardless of generic parameters and regular parameters, needs a separate class. This also serves the important purpose of ensuring delayed initialization for static fields.

void Foo(int a)
{
  static int x = 1; // nested static class <qwe1>Foo_Statics
}
void Foo(string a)
{
  static int x = 1; // nested static class <qwe2>Foo_Statics
}

Can somebody please champion this?

[CyrusNajmabadi]

For generics, I proposed a solution, BTW - nongeneric keyword

Yes. That 'solution' was highly unpalatable. Now for your 'simple' proposal, we have to tack on more and more complexity just got basic cases. This vastly increases complexity both of the design and if what we are foisting on the ecosystem. For much more marginal gains.

I get it. You want this feature and you think it's super important. We do not feel the same way, and we're planning and working on the language based on that assessment on our part.

[TahirAhmadov]

For generics, I proposed a solution, BTW - nongeneric keyword

Yes. That 'solution' was highly unpalatable. Now for your 'simple' proposal, we have to tack on more and more complexity just got basic cases. This vastly increases complexity both of the design and if what we are foisting on the ecosystem. For much more marginal gains.

Why isn't it palatable? I thought we discussed this previously. I know you don't like moving members to a different class in IL, but surely the runtime flag approach should work?

[TahirAhmadov]

How difficult is it to create a "sandbox", put the resulting IL in it and run it?

Extremely difficult.

Even source generators, which are purely additive, and only add source (not even run it), have consumed more than resources than any other feature in the last N releases (outside of NRT). You are talking about an entirely new and complex concept which the language and compiler have never had. This would easily be 2-3 orders of magnitude more complex than utf8 strings (possibly 3-4 even).

I'll defer to your opinion on this for obvious reasons. However, given that JIT unfolding work was done in one major version, and in my mind it's a more complicated endeavor, I just don't share your concern here. Trust me, I understand all kinds of weird things can happen; nothing is ever easy. 100% agree. But to say that this is on the level of NRT effort? Hmmm....

[CyrusNajmabadi]

Why isn't it palatable?

Because the point of having generic code is to let it be generic. If you don't want it to be generic just don't put it in that generic construct, but it in something else that is not generic.

Fundamentally I think it's a broken language construct to even have in the first place. It's like making something as a struct, and then inside trying to say: actually, ignore that, make this a class instead.

[CyrusNajmabadi]

I just don't share your concern here

Then we fundamentally are all an impasse here.

[GrahamTheCoder]

@TahirAhmadov said:

The purpose here is to a) scope a static which is only used in this method, to this method, and b) delay initialization (if any) to prevent a heavy hit on containing class initialization.

I think that's absolutely right. Luckily, it's totally possible to cover those needs nice and explicitly with existing C# syntax.

Therefore I'm pretty against adding a bunch of language-level complexity for this seemingly rare case that'd just be yet another way to achieve almost exactly the same thing with slightly different syntax.

using System;
using System.ComponentModel;
using System.Threading;


public sealed class LazilyInitialized<T>
{
    private T _value;
    private object _lock;
    private bool _isInitialized;
    public ref T EnsureInitialized(Func<T> init)
    {
        LazyInitializer.EnsureInitialized(ref _value, ref _isInitialized, ref _lock, init);
        return ref _value;
    }
}


public class SomeExampleClass
{
    public static void Main()
    {
        var instance = new SomeExampleClass();
        Console.WriteLine(instance.Counter);
        Console.WriteLine(instance.Counter);
    }    
    
    // To avoid cluttering up intellisense
    [EditorBrowsable(EditorBrowsableState.Never)]
    // Declared at the scope it exists in, but no-one can access the value without ensuring it's initialized
    private LazilyInitialized<long> _counter = new();
    public long Counter
    {
        get
        {
            // Use whatever initialization logic you want here
            // It's lazy and executed at maximum 1 time per instance
            ref var localCounter = ref _counter.EnsureInitialized(() => LongRunningFunction());
            
            // Use of the variable otherwise is *not* thread safe (as in VB)
            localCounter += 10;
            return localCounter - 1L;
        }
    }

    public static long LongRunningFunction()
    {
        long i = 1L;
        while (i < 100000L)
            i += 1L;
        return i;
    }
}

If you really wanted to stop other methods being able to use it at all, you can use existing mechanisms such as pulling the field and method into their own class, or a base/sub class depending on dependencies of the method in question.

[TahirAhmadov]

For me, the biggest use case is static readonly fields:

void Foo(string s)
{
  // the regex is only relevant to Foo, therefore we want to hide it from other methods
  static readonly Regex rgx = new("..."); // this is initialized the first time Foo is called; this improves start up costs
  // because if rgx was a field of the containing type, it would be initialized when class is first used
  // but it's entirely possible if you use a subset of a type's feature, you are initializing a whole bunch of stuff you don't need
  var m = rgx.Match(s);
}
SomeDto Bar()
{
  static QueryDescriptor? qd; // this query is only relevant to Bar, therefore we want to hide it from other methods
  return DataAccess.Get<SomeDto>(ref qd, query=>query.Where(x=>x.Property == "bla").FirstOrDefault());
  // the Get method checks if qd is initialized, if not, it parses the LINQ query and creates the SQL query and stores it in qd
  // if qd is initialized, it just runs the stored SQL query. this prevents expensive LINQ query parsing with each query 
}

[GrahamTheCoder]

I don't see any difference (other than an extra line to name/create the nested class) - though I feel like there's another point you're trying to make.

class Class
{
  private Foo _foo = new();  
  private class Foo
  {
      int x = 0; // this static field is only visible in Foo
      public void Execute() => ++x;
  }
  
  private Bar _bar = new();  
  private class Bar
  {
      int y = 0; // this static field is only visible in Bar
      public void Execute() => ++y;
  }
    
  void OtherMethodInClass()
  {
        _foo.Execute();
        _bar.Execute();
        ++x; // error CS0103: The name 'x' does not exist in the current context
        ++_foo.x; // error CS0122: 'Class.Foo.x' is inaccessible due to its protection level
  }
}

Note there are many trivial ways to make it lazy and keep that laziness within Foo, I picked an arbitrary one

using System;
using System.Text.RegularExpressions;

class Class
{
  private Foo _foo = new();  
  private class Foo
  {
      readonly Lazy<Regex> rgx = new(() => new Regex("...")); // the regex is only relevant to Foo, therefore we want to hide it from other methods
      public void Execute(string s) => rgx.Value.Match(s);
  }
  
  private Bar _bar = new();  
  private class Bar
  {
      QueryDescriptor? qd; // this query is only relevant to Bar, therefore we want to hide it from other methods
      public SomeDto Execute() => DataAccess.Get<SomeDto>(ref qd, query=>query.Where(x=>x.Property == "bla").FirstOrDefault());
  }
    
  void OtherMethodInClass()
  {
        _foo.Execute("example");
        _bar.Execute();
        rgx; // error CS0103: The name 'rgx' does not exist in the current context
        _foo.rgx; // error CS0122: 'Class.Foo.rgx' is inaccessible due to its protection level
        qd; // error CS0103: The name 'qd' does not exist in the current context
        _bar.qd; // error CS0122: 'Class.Bar.qd' is inaccessible due to its protection level
  }
}

I haven't understood your point any further, so if you haven't understood mine further either, I suggest we leave it there. Thanks for the discussion!

[TahirAhmadov]

I don't see any difference (other than number of lines)

That is an important point. This change is chiefly aimed at making something easier; it doesn't allow something that was previously completely impossible. As discussed previously by many others, including members of LDT, C# is not just about making things possible, but equally importantly it's about making things elegant.

Looking at your first sample, I'll make some changes to reflect a real-world use case:

class Class
{
  public Class(int field)
  {
    this._field = field;
    this._foo = new FooClass(this); // BTW this is an unnecessary allocation
  }
  public void Foo(string s, int i)
  {
    this._foo.Execute(s, i);
  }

  class FooClass
  {
    public FooClass(Class owner) => this._owner = owner;
    public void Execute(string s, int i)
    {
      x += this._owner._field + s.Length + i; // this._owner._field introduces an unnecessary indirection
    }
    readonly Class _owner;
    static int x = 0; // this static field is only visible in Foo
  }

  readonly FooClass _foo;
  int _field;  
}

Compare the above to:

class Class
{
  public Class(int field)
  {
    this._field = field;
  }
  public void Foo(string s, int i)
  {
    static int x = 0; // this static field is only visible in Foo
    x += this._field + s.Length + i;
  }

  int _field;  
}

Which one of these two approaches would you like to see?

[GrahamTheCoder]

Allocation: Since it's static you can just make the class static to avoid the allocation. If it was non-static you could just switch it to a struct instead. Static example tidied up:

class Class
{
  public Class(int field)
  {
    this._field = field;
  }
  public void Foo(string s, int i) => FooClass.Execute(_field, s, i);
  static class FooClass
  {
    public static void Execute(int field, string s, int i) => x += field + s.Length + i;
    static int x; // this static field is only visible in Foo
  }
    
  int _field;  
}

In general I'd factor classes out into potentially reusable, decoupled components, which I assume is why I've never come across the need for this. But in the scenario we're discussing where that's not desirable, seeing this in the codebase wouldn't cause me a moment of consternation. To me, the way to encapsulate methods and data together is a class/struct, so I'd happily create one if needed.

equally importantly it's about making things elegant

I'm all for elegance of very common patterns as a reason to change the language, though it's generally subjective on most fronts. For me, the balance of elegance falls on the side of keeping the language itself more streamlined in this case. Lots of the C# features are a close call on this one, so it's lucky we're all able to discuss it from our differing experiences.

[TahirAhmadov]

What if you had to make a static field modification, as well as an instance field modification?

class Class
{
  public Class(int field)
  {
    this._field = field;
  }
  public void Foo(string s, int i)
  {
    static int x = 0; // this static field is only visible in Foo
    this._field += s.Length + i;
    x += this._field;
  }

  int _field;  
}

You are right - it's possible to get rid of the performance overhead by using a struct in that case.

class Class
{
  public Class(int field)
  {
    this._field = field;
    this._foo = new FooStruct(this); 
  }
  public void Foo(string s, int i)
  {
    this._foo.Execute(s, i);
  }

  struct FooStruct
  {
    public FooStruct(Class owner) => this._owner = owner;
    public void Execute(string s, int i)
    {
      this._owner._field += s.Length + i;
      x += this._owner._field; 
    }
    readonly Class _owner;
    static int x = 0; // this static field is only visible in Foo
  }

  readonly FooStruct _foo;
  int _field;  
}

This is still much worse than the concise option using the proposed syntax.
Regarding your example of static class, that's an option - for each case, imitate "static locals" in a different way. If it can be made static, it's one form; otherwise, use a different form; etc. The problem there is the lack of consistency. Reading this code requires complex deduction of intent; somebody who comes across the struct FooStruct or static class FooClass situation has no idea why those exist, and needs to reverse engineer the original author's thinking process.

In general I'd factor classes out into potentially reusable, decoupled components,

That's nowhere near the situation here. There is nothing to re-use or decouple. I just need to keep the static field, which is used by one method only, inside that method. This is completely different than:

To me, the way to encapsulate methods and data together is a class/struct, so I'd happily create one if needed.

And that's another problem: this isn't strictly needed. I can just make my regexes and queries as static fields of the containing types, and prefix the name with the method name - which is exactly what I'm doing. Nobody, absolutely nobody, will create that static class or struct contraption just to make the code a little cleaner by hiding these static fields. These are two opposing things: we're trying to clean up the code, by getting rid of static fields from the containing type, because they're only relevant to one particular method; and to accomplish that, we're creating (in your world) a whole new nested type, with all the indirection, wrapping, etc. It's like, swerving into the oncoming path of a heavy truck to avoid hitting some bushes; avoid a few bumper scratches and get a life-threatening injury instead. Same here - get rid of a field or two, and get a whole new type to type and maintain.

I'm all for elegance of very common patterns as a reason to change the language, though it's generally subjective on most fronts.

If you have the opinion that having 11 more lines of code for no reason is "elegance", that's fine - you, like everybody, are entitled to your own opinion. To me, this is the opposite of elegance.

[mikernet]

In terms of syntax, I find it a bit awkward that the field init code is directly inside the method block but only runs the first time the method is called and is skipped on subsequent calls. What if there was a way to separate the field stuff, something like:

void IncrementCounters()
{
    fieldinit {
        int counter = 0;
        static int s_counter = 0;
        
        // Allows for more complex multi-line initialization as well:
       SomeClass field = new();
       field.DoSomeInitStuff();
    };
    
    counter++;
    s_counter++;
}

Syntax can be discussed, but separating it out into its own block would make it clearer (especially for beginners) as to what is going on. I think it makes it easier to reason about when it is clearer which lines of code are skipped on subsequent calls. This also "fixes" the issue of how to indicate whether you want a static or instance field, as it is now done the same way as before inside the fieldinit block.

[miyu]

This would be cool. A few concerns from my end:

1. variables declared in a block are now accessed outside of the block, which doesn't exist anywhere else in C#.
2. variables are hoisted, which moves their declaration far from their use. The pro is all initialization happens in one spot. The con is more scope pollution within the function and lower code clarity due to the loss of locality.

[TahirAhmadov]

While I understand the concern with it being potentially confusing, I don't think it's that big of an issue. Developers will get used to it quickly; it's similar to field/property initializers, and everybody knows those are executed once only. Between issues raised by @miyu, and just the added effort of adding a new keyword, writing that extra scope, I think it's easier to just educate the developers on how to use this correctly. And C#, as far as languages go, is very well documented; this new feature, if it's ever done, will be no exception.

[miyu]

Two alternative approaches worth discussing:

• Permitting Attributes to be used with local variables, then leaving static locals to 3rd-party IL Rewriting.
• A __unique_struct keyword, which the compiler transforms into a unique struct SomeUniqueName {} at every site. End-users can use __unique_struct to build a form of static locals themselves.
  • As discussed below, if __unique_struct is used in Class<T>.Method<U>, I propose it generates a struct global::NameSpace.Class_Method_unique_struct123, dropping T and U.

Local Variable Attributes + IL Rewriting

Permitting Attributes to be used with local variables would allow us to write code as follows, then rewrite the IL to leverage a static via something like Fody. Maybe this is a nontrivial breaking change to IL? This shifts the problem of "when is static initialized", "what if we want to declare instance fields in a function" to the library.

class C {
   int MyFunction() {
      [Static] var x = 10; // Declares static class CMyFunction_statics { static int x = 10; }
      return x++; // IL-rewrite to CMyFunction_statics.x++
   }
}

I guess technically this can already be done via IL Rewriting with something like: var x = MyMagicILWeavingLibrary.StaticLocal(10), though that doesn't exactly read like C#.

__unique_struct

__unique_struct could likewise be used to avoid polluting a specific class with mangled static names (e.g. littering static int MyFunction_x = 10 above MyFunction). The below code isn't thread-safe, but hopefully gets the point across.

The nice thing is, everything builds on top of existing C# semantics; we're not really introducing any new concepts beyond __unique_struct.

static class Statics<TValue, TUnique> {
   private static TValue s_Value;
   private static bool s_isFirstAccess;
   public static ref TValue GetRef(out bool isFirstAccess) {
      isFirstAccess = s_isFirstAccess;
      s_isFirstAccess = false;
      return ref s_Value;
   }
}

class C {
   int MyFunction() {
      ref var x = Statics<int, __unique_struct>.GetRef(out bool isFirstAccess);
      if (!isFirstAccess) {
         x = 10;
      }
      // ... additional computation
   }
}

Alternatively you could use __unique_struct slightly differently:

static class Statics<TValue, TUnique> {
   private TValue value;
   private ?? someSynchronizationState; // use interlocked or mutex to ensure factory() is run once

   public static TValue GetOrInit(Func<TValue> factory) {  /*...*/ }
}

class C {
   int MyFunction() {
      var reusedList = Statics<List<int>, __unique_struct>.GetOrInit(() => new());
      // ... additional computation
   }
}

Another approach:

static class Statics<TValue, TUnique> {
   private TValue value;
   public ref TValue Get() => ref value;
}

class C {
   int MyFunction() {
      var reusedList = Statics<List<int>, __unique_struct>.Get() ??= new();
      // /* Or maybe: */ var reusedList = Statics<List<int>>.Get<__unique_struct>() ??= new();
      // /* Or maybe: */ var reusedList = Statics<__unique_struct>.Get<List<int>>() ??= new();
      // ... additional computation
   }
}

Likewise, you could have a TLS<TValue, TUnique> class, if you wanted the reused list to be in thread-local storage.

Of course, with __unique_struct you still run into the question of how it interacts with generic classes and generic methods. My proposal would be to drop any containing generic arguments and hoist __unique_struct to its containing namespace, e.g. Class<T>.Method<U>.__unique_struct would become Class_Method_unique_struct123; then, if needed end-users could run write code like Statics<TValue, (T, __unique_struct)> to get a static local distinct for every T, or Statics<TValue, (T, U, __unique_struct)> to get a static distinct for every ordered T, U pair.

[TahirAhmadov]

Re. attributes - how is that better than the static keyword, which already exists? I'm not sure what you mean by "3rd party IL rewrite". Do you mean a special process which runs after the compiler, and recreates the EXE/DLL? That would be an option, I guess, but attributes cannot be applied to locals; so it's a language change anyway.
Re. __unique_struct - I can see how that could be made to work, but given it requires a language change anyway, why not just use the simple static int x = 10; approach?

[Xyncgas]

I wish there's a summery on github that makes it a little bit more clear what people are talking about, so are we gonna do this or not

[HaloFour]

This proposal has no champion.

[Xyncgas]

I have a question I also see readonly local being champion, if there's so many champion waiting for people to work on it and bring it to the language design meeting why not hire more people to do it given how much money microsoft has, more feature means more competitive on the market, and better dev experience leads to more people making users happy which in turns pay for stuffs

[HaloFour]

It's not a question of money or resources, it's a question of whether or not the feature fits within the language. Being "championed" does not mean that the feature will be implemented, only that someone from the language team is willing to discuss it amongst the rest of the design team. That doesn't mean that the team will agree to do it. As is the case with "readonly locals and parameters" not enough people on the team find the value in it, at least as of now.

The bar for any additional is exceptionally high, not because it's expensive in terms of people-hours, but because a language that is 20 years old and intended to last another 20 years needs to be designed and evolved very carefully and very intentionally. The vast number of proposals here will never meet that bar.

[CyrusNajmabadi]

Questions about readonly-locals should be taken to #188. I'm hte champion of that proposal and can answer any questions you may have about it.

[zms9110750]

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

Sorry, I didn't understand it. How do you know to use this cached value? He has no name.
Can this cached value only be accessed from the same method?

[Xyncgas]

Local variable that outlives the local is an awesome concept if not one the the most important one we are getting.
It allows an easier, more elegant way, for explicit capturing for lambdas.
Considering something you are creating inside the lambda, perhaps a new array or maybe a new http client, instead of creating a new one whenever you execute the lambda you can create one that will live as long as the lambda itself will live.
This applies for instance methods as well, it's executable via creating a hidden class by the compiler or putting these variables in the instance but make them invisible or visible via special syntax like Instance.MethodName.StaticLocalVariable
I wonder if we should still call them static variable, since in most cases and this case, it lives as long as the instance

[Xyncgas]

This means sometimes instead of creating an object for the sake of composition, you just write the code that does your stuff and put the things you need to do the job in the code while declaring them as static to avoid repeatedly calling new, while leaving definitions of data structures a closer representation of what we are actually dealing with setting a bright future for the object oriented experience

[Xyncgas]

You can implement this via compiler magic, we can do this today

        public delegate Action Δ(params object[] OOO);
        public delegate Action<T> Δ2<T>(params object[] OOO);
        public delegate Func<T> Δ3<T>(params object[] OOO);
        public delegate Func<C,K> Δ4<C,K>(params object[] OOO);
        public static void AScope()
        {
            List<int> intarr = new();
            Δ k = (e) => () => 
            {
                //static List<int> intarr = new();
                //Gets promoted as shown here

                //var intarr = (List<int>)e[0];
                //this is what compiler does automatically

                intarr.Add(5);
                //This is the regular user experience
            };
            k(intarr)();//Pass explicit cpaturing static local variables
            k(intarr)();//intarr outlives the function body of k
            Δ2<int> k2 = (e) => (l) =>
            {
                //static List<int> intarr = new();
                //Gets promoted as shown here

                var intarr = (List<int>)e[0];
                //this is what compiler does automatically

                intarr.Add(5);
                //This is the regular user experience
                return;
            };
            Action<int> Mymethod2 = k2(new List<int>());//Pass explicit cpaturing static local variables
            Δ3<int> k3 = (e) => () =>
            {
                //static List<int> intarr = new();
                //Gets promoted as shown here

                var intarr = (List<int>)e[0];
                //this is what compiler does automatically

                intarr.Add(5);
                //This is the regular user experience
                return 0;
            };
            Func<int> Mymethod3 = k3(new List<int>());//Pass explicit cpaturing static local variables
            Δ4<int,int> k4 = (e) => (l) =>
            {
                //static List<int> intarr = new();
                //Gets promoted as shown here

                var intarr = (List<int>)e[0];
                //this is what compiler does automatically

                intarr.Add(5);
                //This is the regular user experience
                return 5;
            };
            Func<int,int> Mymethod4 = k4(new List<int>());//Pass explicit cpaturing static local variables
        }

Your static local lives as long as the method itself, if it's a lambda using static local it means as long I have a reference to the lambda I created the objects (static locals) lives, if it's an instance method it means as long the instance lives the objects lives

[Xyncgas]

However the example displayed is not the complete image, for example you need to be able to refer to the members of the instance where your regular function is in, that means you do the capture in constructor.
So instead of :

class MyClass
    {
        public Action MyMethod = new Δ((e) => () => {


        })(new List<int>());
    }

Do

class CompilerGenerated_ABC123
{
        public CompilerGenerated_ABC123 () => MyMethod = new Δ((e) => () => {


        })(new List<int>());
        public Action MyMethod_;
}
class MyClass
{
        private CompilerGenerated_ABC123 Magic; //somehow
        public void MyMethod ()=>CompilerGenerated_ABC123.MyMethod_;
}

[Xyncgas]

An alternative pattern without static local is returning a function instead of what your original method is returning.
You are explicit capturing via the power of lambda.
So static local is basically a syntax sugar

abstract ValueTask<string> GetMessageByID(int ID, Dictionary<int,string> Cache);
public Func<int,ValueTask<string>> MessageReader()
{
        var Cache = new Dictionary<int,string>();
        return async(Id)=>await GetMessageByID(Id,Cache);
}

Assuming static local lives as long as the instance, it's equivalent to

abstract ValueTask<string> GetMessageByID(int ID, Dictionary<int,string> Cache);
public async ValueTask<string> MessageReader()
{
        static var Cache = new Dictionary<int,string>();
        return await GetMessageByID(Id,Cache);
}

Where MessageReader is a member method

[Xyncgas]

Returning everything as function is one way to use C# in my opinion.
Of course you still have ViewModels and S3-Credentials and stuffs that makes sense to visualize / represent as a record struct.
However with the compiler creating hidden classes for you via lambda capturing you don't need to write a lot of classes

[Xyncgas]

Because it's true lot of times you are dealing with representation.
Yet a lot times it is the memory management that require us to has a reference to an array in one way or another to refrain from costly provision of availabilities.
Although one may choose the extreme and never reuse any buffer, leaving the memory pressure management to the memory pooling, which is another challenge for the .NET technology's stability

[Xyncgas]

Just another thing I think of, if we can reference statics defined in local / function scope, we can do it with enums defined in function scope too :
So if we can

void A (int a) => a+B.b;
void B ()
{
    static int B = 0;
}

It makes sense to use a enum defined in another function in the same syntax

void A() => B(B.SeqMax);
void B()
{
    enum Seq{Min, Max}
}

Is legal

Even
void B (enum Seq {Min,Max}) { if(Seq == Seq.Max) { Console.WriteLine ("Hello World"); } }

What a beautiful world

[Xyncgas]

We shoud change the title to static local, since it is referred to the feature exists in VB called static locals too

[Shadowblitz16]

I disagree this is c sharp not vb sharp

[ejball]

CA1861 has me wishing for static locals again...

[DavidArno]

... The compiler simply needs to autogenerate an actual field for it in IL, the same thing it does for tons of other stuff already, just think about the new primary constructor parameters for example

Shhh, we aren't supposed to mention that PC parameters end up as fields when "captured". That's an "implementation detail", apparently 🤷

Leaving aside the shenanigans around how the spec describes PC parameters, your point is well made. The language supports static local functions, so why not static local variables? The team could even make storing them as static fields, an "implementation detail" if they really wanted to.

[HaloFour]

That implementation detail has policy concerns, regardless of how the language specification states they work or how the compiler decides to implement them. There isn't a single way to implement this, which is obvious by the fact that static locals work differently in different languages today (e.g. C++ vs. VB). It's not just a matter of where to put it.

[CyrusNajmabadi]

Shhh, we aren't supposed to mention that PC parameters end up as fields when "captured".That's an "implementation detail"

Hunh? You are free to mention this. It's just, as you said, an implementation detail. It's not something you could/should take a dependency on as it can change at any time. The same as captures. They can and do change from version to certain.

The language supports static local functions, so why not static local variables?

As mentioned, even in the community there are disagreements about the semantics of statics in methods.

The point about static functions doesn't hold. There is no concern about semantics (since the user is not in control of assigning or reassigning the value).

[DavidArno]

That implementation detail has policy concerns

"Should it be a static field or an instance field" seems the only real discussion that's gone on in this thread. There again, I've not re-read it recently so that might be selective memory on my part. What other policy concerns are there?

And if both are needed, just use something like private instead of static for the instance-based locally encapsulated fields:

class C
{
    void Foo()
    {
        private var FooCache = new Dictionary<int,string>();  // every instance of C gets it's own FooCache
        ...
    }

    void Bar()
    {
        private static var BarCache = new Dictionary<int,string>();  // One instance of bar cache is shared across all C's
    }
}

[HaloFour]

Plus whether or not static means that there should be exactly one value, or a value per closed generic type.

class C<T>
{
    void Bar()
    {
        // One instance of BarCache for C<int> and another for C<string>?
        private static var BarCache = new Dictionary<int,string>();
    }
}

Plus what kind of thread-safety should be employed:

void M() {
    // can SomeExpensiveCalculation be called more than once if two threads call the method simultaneously?
    private static var value = SomeExpensiveCalculation();
}

Obviously not an insurmountable concern; the language can just pick one and go with it. But none of the decisions are "obviously" correct or better over the other.

[TahirAhmadov]

All of the questions raised above are answered in this proposal - static/instance, generics, and thread safety:

class MyClass
{
  int _x = 5;
  int c = 123;
  static int _s = 456;

  public static void Foo() // static method
  {
    static int a = 5; // triggers the creation of a private static nested class of MyClass,
    // named something like "<generated>Foo_Statics" (using similar logic to anonymous types, etc.)
    // same as adding the following to Foo_Statics: static int a = 5;
    static var b = 8; // allow "var" syntax to be consistent with other locals; "static int b = 8;" in "Foo_Statics"
    static int c = a + b; // allow referencing other static locals
    static int d = _s + c; // allow referencing type-scoped static fields
    static string e; // this is included in nullability analysis (warning: e is potentially null)
    static string? f; // no warning here - f == null by default
    static string g = "abc"; // same here - g is initialized, so not null
    static readonly Regex rgx = new Regex("..."); // this is very useful - defer initialization to this method being called. 
    // Same as adding this to aforementioned "Foo_Statics": static readonly rgx = new Regex("...");
    // Regular framework handling of thread-safe static init works fine on "Foo_Statics"
    ++a; // same as: ++Foo_Statics.a;
    Console.WriteLine(a);
    int bLocal = Interlocked.Increment(ref b); // gotta be thread safe sometimes
    Console.WriteLine(bLocal);
    var m = rgx.Match("..."); // same as: var m = Foo_Statics.rgx.Match("...");
    Baz(static new[] { "a", "b", "c" }); 
    // adds the following to Foo_Statics: static readonly string[] <InlineLocal>ASDASD = new[] { "a", "b", "c" };
    // the call becomes: Baz(Foo_Statics.<InlineLocal>ASDASD);
  }
  public void Foo<T1, T2>() where T1 : IDisposable
  {
    static int a = 5; // the statics class is generic, copying it's generic signature from Foo<T1, T2>
    // same as: private static class <mangled>Foo_Statics<T1, T2> where T1 : IDisposable { static int a = 5; } 
    static T1? b; // we can use method's generic arguments for these static local fields, which is a great plus

    static nongeneric int c = 6; 
    // creates MyClass_Foo_T1_T2_NonGenericStatics class (below)
  }
  public void Bar() // instance method
  {
    static int a = 5; // works identically to Foo: class Bar_Statics { static int a = 1; }
    static readonly Regex rgx = new Regex("..."); // this is very useful in instance methods, too
    ++a; // same as: ++Bar_Statics.a;
    Console.WriteLine(a);
    var m = rgx.Match("..."); // same as: var m = Bar_Statics.rgx.Match("...");

    // I think the below isn't super helpful, but for those who want the benefits of scoping, here goes:
    instance int c = 5; // adds a private field to MyClass named something like "<generated>Bar_c"; 
    // field is set to 5 when class is created, as usual. 
    // Note the introduction of a new keyword (has to be decided if it can be contextual)
    // "c" is very similar to "_x"; it's only different in scoping
    // it is DIFFERENT than MyClass.c field:
    ++c; // increment the instance local field
    ++this.c; // increment the class-scope field declared on top
    instance int d; // same as above, but no initialization, defaults to 0
    instance string e; // this is included in nullability analysis (warning: e is potentially null)
    instance string? f; // no warning here - f == null by default
    instance string g = "abc"; // same here - g is initialized, so not null
    //instance readonly int h = 1; // I think this doesn't really work; constructor cannot see this field, 
    // so it can only be assigned a constant; at which point it's no better than a static readonly field (see above)
  }

  public static int StaticProp
  {
    static int staticProp;
    get => staticProp - 5; set => staticProp = value + 5;
  }
  public int Prop
  {
    static int staticField;
    instance int prop;
    get => prop - 5; set { prop = value + 5; ++staticField; }
  }

  public static event EventHandler StaticEvent
  {
    static int staticField; // this can be useful, I suppose
    static EventHandler v; // this is pretty useless - unless we allow defining the getter below
    add { v += value; ++staticField; } remove { v -= value; --staticField; } private get { return v; }
  }
  public event EventHandler Event
  {
    static int staticField; // this can be useful, I suppose
    instance EventHandler v; // this is pretty useless - unless we allow defining the getter below
    add { v += value; ++staticField; } remove { v -= value; --staticField; } private get { return v; }
  }
}
// this class is created due to "nongeneric" keyword inside a generic method
static class MyClass_Foo_T1_T2_NonGenericStatics
{
  internal static nongeneric int c = 6; 
}

MyClass.Foo(); // outputs "6" and "9" to console
MyClass.Foo(); // outputs "7" and "10" to console
new MyClass().Bar(); // outputs "6" to console
new MyClass().Bar(); // outputs "7" to console

[CyrusNajmabadi]

@TahirAhmadov

if (collectingExpensiveData)
{
    static ExtremelyExpensiveData dataThatIsRooted = ComputeVeryExpensiveData();
}

If i write this, and now my expensive data is not only executed, but rooted, despite collectingExpensiveData then that's going to be very bad.

[TahirAhmadov]

If i write this, and now my expensive data is not only executed, but rooted, despite collectingExpensiveData then that's going to be very bad.

Like I said previously, that if branch can be extracted to a separate method; that's one option.
Another option is static Lazy<ExtremelyExpensiveData> dataThatIsRooted = new(()=>ComputeVeryExpensiveData());.

With both options above, developer knows when the computation is expensive, and decides whether granularity is called for.

Whereas you want to decide across the board the granularity is the right approach; and add to that - the effort to try optimizing the obviously needless expressions away into "eager" approach.

Again, the minor performance hit (which you promised won't be there really) may be acceptable if the method in question does something slow, like a DB query, etc.; I still think this will be beneficial to add - even if I don't think your approach is ideal.

[HaloFour]

With both options above, developer knows when the computation is expensive, and decides whether granularity is called for.

IMO it's not important that there are options. What is important is what a developer would be expected to intuit about the feature given their knowledge of the language and similar features. Otherwise developers are likely to accidentally misuse the feature and introduce errors/bugs into their program very unexpectedly.

You're starting with an idealized implementation and trying to work backwards towards language semantics, which is not how a language should be designed.

[HaloFour]

Does it help the discussion when Halo claims that "Yet nobody has asked for them?" when literally OP mentions it near the top?

You're right, OP does mention it, as a possible alternative syntax. Although OP also explicitly mentions statics as implemented in VB.

IMO static locals would make static expressions unnecessary. I'd prefer the ceremony of the local to make it painfully obvious that the assignment behaves differently, whereas a static expression could easily be missed or misunderstood.

[HaloFour]

I think this is just going in circles and I don't know that opinions are changing at all, so it's probably best to leave it as it is. As it stands, none of this is championed even after at least nine years, and the more complicated it gets the less likely that seems like it would be.

[ctw1000]

Hello - I've been directed here from another discussion thread (#8038)
in which I have been asking for what appears to be similar to that being asked for here.
.
So - please add me to the list of people who want this feature!
.
.
My particular imagination of the idea would be to allow
local function variables that retain their state between function calls.
.
Underneath I imagine them being actually private class variables
that have the scope of only this one function.
.
Although we'll declare it INSIDE the function with a new keyword.

eg
class MyClass
{
public void IncrementValue()
{
preserved int thisIntRemembersItsValueBetweenCalls = 1;
//
thisIntRemembersItsValueBetweenCalls++;
}
}

.
To answer some details...

Q: When would it be initialized?
Ans: I think it should be treated as if it is a private class variable.
(it just appears to the programmer that it's inside the function when really
it's a member of the owning class instance).
So therefore it gets initialized during creation of the class.

Q: What happens if that method is called from multiple threads?
Ans: In keeping with what would happen to a class variable - the same
variable instance would be updated.

So in the above example if we did
MyClass theClass = new MyClass();
and thread one calls:
theClass.IncrementValue();
then thread two calls:
theClass.IncrementValue();

• then we've incremented it twice (leaving thisIntRemembersItsValueBetweenCalls == 3)

Hoping someone picks up on this again!