Allow local variables to be static and/or readonly (deeper scoping) about roslyn

[sharwell]

💡 If you are going to allow static (without the readonly modifier), you should probably update this to allow static volatile as well.

[HaloFour]

@shunsukeaida VB.NET already has Static variables which behave as described by this feature request. The keyword was inherited from pre-.NET versions of VB.

Implementing ReadOnly variables would be a new feature for VB.NET, though.

For readonly variables I'm personally a fan of the Apple Swift syntax which uses let as an alternative to var, e.g.:

var x = 1;
let y = 2;
x = 3; // legal
y = 4; // compiler error, y is readonly

[bondsbw]

Should this work with properties? If so, then what rules make sense? Would the following work?

public int Foo
{
    get { return foo; }
    set
    {
        static int foo = 0;
        foo = value;
    }
}

Same question vice-versa, and also with event add/remove accessors.

Related: #850, #12361

[matwilko]

Love this idea 👍

My ten cents on how to somewhat simplify the idea so that the problems of eager/lazy initialization hopefully go away is to just restrict the semantics of the declaration to mean that it is a private instance/static field on the class, but lexically scoped only to the method.

This makes the hoist completely trivial - just give it an "unpronounceable" name - and the compiler rewrites references to it with the new name in the method.

It also solves the initialization problem as the semantics are the same with any other instance/static field. If there is an initializer, the restrictions on it are the same as for regular initializers, and it is run at the same time as other instance/static initializers.

If there isn't an initializer for non-readonly fields, it's up to the method to do any necessary initialization and locking etc. if thread safety is required. Alternatively, constructors could be allowed to set the field via MethodName.fieldname = blah; , much like they can for get-only auto-props now, although this falls apart when more than one overload uses an identically named method-local field :/

If the developer wants lazy semantics for the field - it's just the same as with a "normal" field, declare it as type Lazy, and refer to field.Value in the method.

Multi-threaded scenarios are also explicitly not handled, as is the case with normal fields.

I think all this fulfils the principle of least astonishment better as the syntactic sugar is incredibly thin, and it means that we get better scoping without having to worry about some complicated codegen going on underneath (which could change assumptions about things like memory use/locality etc.)

[sharwell]

For static local variables with an initializer, it seems like you could hoist the local to be a static member of a compiler-generated private nested class. This way you can still use a static constructor (of the nested class) to initialize the value, but in many cases avoid initializing the value until the first time the method is called.

[matwilko]

Don't we then reintroduce the problem of making it harder for the developer to know easily at a glance when the field is going to be initialized? And what if I explicitly don't want the lazy semantics?

[paulomorgado]

Other than constants that are literally replaced at compile time (as all constants are, but these wouldn't have a field), if static scoped fields are to added, why not instance fields?

@matwilko, I agree with @sharwell. It makes a lot more sense to expect the field to be initialized on the first execution of the method. After all, it's where it's declared on the source. If you want/need it to be initialized elsewhere, than it's not logically scoped to the method.

[s-aida]

On a silly note, if this feature is introduced as static variables in a local scope , then for VB would it be a shared variable that is actually NOT shared by anything else? 😛

[s-aida]

I know of VB's static but oh I didn't think it was equivalent to this feature which asked for non-reallocable local variable, and VB's static is something you'd use in a pretty procedural programming.

But yeah, the third example is what VB's static is for.

[matwilko]

@paulomorgado Fair enough :) Was just trying to simplify it down enough to avoid needing the debate on how and when to initialize the field when it's an instance field (the static case was always going to be pretty simple)

The use of a Lazy to get the lazy-initialization for instance fields just feels a bit heavy to me, it adds a layer of indirection, (potentially) reduces locality, and requires a delegate to be instantiated, which all seems a bit much for what should be a lightning fast and memory-efficient field access.

We could add manual locking with only an extra bool and object (to act as initialization check and locking object)? This keeps the field local to the object in memory, requires minimal extra memory to be used, and only results in one extra allocation.

[MadsTorgersen]

This is a proposal for two distinct features, which are expressed individually in #115 and #10552.