Comments (11)
💡 If you are going to allow static
(without the readonly
modifier), you should probably update this to allow static volatile
as well.
from roslyn.
@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
from roslyn.
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.
from roslyn.
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.)
from roslyn.
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.
from roslyn.
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?
from roslyn.
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.
from roslyn.
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? 😛
from roslyn.
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.
from roslyn.
@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.
from roslyn.
This is a proposal for two distinct features, which are expressed individually in #115 and #10552.
from roslyn.
Related Issues (20)
- Errors for scoped differences in override indexers are missing in some cases HOT 1
- VB Span Perf Issue HOT 2
- F1 on type parameter symbols declared in source opens MSDN at completely unrelated pages
- Debug breakpoint step over throws an access violation exception
- Trying to jump out of local function after a using declaration causes internal error: 'given key was not present in dictionary' HOT 3
- Signature help does not appear for target typed new with partial parameter HOT 1
- error MSB6006: "csc.dll" exited with code 139 on almost empty project HOT 1
- Collection expression overload resolution should chose type with valid .Add method HOT 2
- Public API for partial properties HOT 2
- Hot Reload fails to apply change with IndexOutOfRangeException HOT 1
- "Implement interface" IDE options disappear when the class has a static member with the same name
- Hot Reload: Allow extern functions to be added HOT 2
- Error CS0121 with overloads of params and generic parameters HOT 3
- False positive 'possible null reference argument' after ensuring non-null via the null coalescing operator HOT 1
- Completion Service does not provide all methods available. HOT 5
- C# snippets don't work if LSP Roslyn editor is enabled HOT 1
- Raw string guide line isn't shown in "Peek definition" window
- [API Proposal] Linq-like APIs for analyzers
- Possibly unintended reuse of `ref` local to `in`/`ref readonly` parameters causes unexpected mutation HOT 2
- `System.InsufficientExecutionStackException` thrown in `LocalBinderFactory` compiling `ErrorFacts.IsBuildOnlyDiagnostic()` on MacOS
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from roslyn.