Dax, actually you are misunderstanding how it is supposed to work.
If you have a field that can't be null, it must be initialized or else the construction fails.
Then, if you try to set null to it is supposed to fail, using reflection or anything else.
So, there's no need to check for "unchecked" or anything else.
And, considering .NET doesn't really have a not-null for reference types, it simply means that any method that uses the field, variable etc will start by checking if the value is different than null, throwing an exception if it is null (a different one than NullReferenceException... maybe the ArgumentNullException for input arguments)... yet, the compiler could help by disallowing, at compile-time, passing null constants or expressions known to return null.
I also published an article on how the same resource (the StackSaver, Coroutine or ManagedFibers) could be used to do the same job of the async/await pair, but without requiring specific return types (which also makes general-purpose interfaces more prepared for future changes, as you don't risk breaking your code if some implementation needs to be "awaitable").
The article is at: http://www.codeproject.com/Articles/357724/Async-Await-Could-Be-Better
After many research, I finally understood the right names.
So, the StackSaver class that I am commenting may very well be named Coroutine. I already implemented a StackSaver class using full-threads, but I am sure it will be better avoiding new real-threads. Also, I did find that Fibers already allow such "stack-saving" and the creation of coroutines in the normal windows API, unfortunatelly it does not work in .Net even with p/invokes (ok, it works for some time... but then it crashes... I am sure it is related to garbage collection as the .Net does not see the alternative and unmanaged callstacks).
So, I should put it here: Add managed Fibers to .Net.
In fact, my implementation on the matter (my POLAR compiler/interpreter) only updates a reference (a pointer). So, you are right, it will not copy the stack, it can only update a single pointer and make everything work.
I am actually creating a new compiler/interpreter and I am using it to prove the concept. You can see it working here: http://www.paulozemek.com/Polarlight.TestPage.aspx
It uses the "stacksaver" for a method, and than yield returns at any moment, be it under finally blocks, be it from inner methods. In either case, it does not have any special return type.Paulo Zemek shared this idea ·
1,374 votesunder review · 13 comments · Visual Studio IDE » UWP / WPF / XAML Tools · Flag idea as inappropriate… · Admin →Paulo Zemek supported this idea ·