Bring back the Singleton<T>?

[OneFingerCodingWarrior]

About the singleton, following thread had discussed a lot
#3134 (comment)

but recently, i found the following pattern

public class MyClass
{
    private static MyClass _ins = null;
 
    public static MyClass Ins
    {
         get {return LazyInitializer.EnsureInitialized(ref _ins, () => new MyClass()};
    }
}

The Pattern is copied from the book "CLR Via C# 4th Edition by Jeffrey Richter Chapter 30 The Famous Double-Check Locking Technique"

i mean it's been over 10 years, we still keep writing wrong codes, again and again.
Since the WCT is widely used by many developers, i think it's a good place teaching people writing the right codes

so in a word, should you guys bring back the Singleton?

BTW, the book also state, FCL class guarantee the static method is thread safe(according to the book)

[michael-hawker]

@OneFingerCodingWarrior as the issue on why we removed Singleton states to achieve this with C#, you just need to do this:

public static MyClass Instance { get; } = new();

That's it. That's why we removed the class as it's trivial to do now. We updated our code in the Toolkit to do this. I believe we had a deprecation message mentioning this as well.

FYI @Sergio0694

(Also, please don't paste an excerpt of copyrighted material in full, I've deleted your 2nd comment.)

[Sergio0694]

To add to this, one benefit of this approach other than being much more concise and only using language syntax with no external types or helpers, is that it's inherently thread-safe, unlike original snippet that's not. That Ins property that @OneFingerCodingWarrior showed can potentially both run the constructor multiple times if invoked concurrently, and in the worst case (depending on how that EnsureInitialized method is implemented, it might also return different instances and therefore causing all sorts of potential issues in other parts of your app 😄

Now to answer to the other question, the advantage of using this approach is that it causes the C# compiler to emit a static readonly field initialized with that instance, and to make the whole type as beforefieldinit, which might enable other further optimizations on the runtime side. Additionally, static readonly fields can be further optimized by the JIT and be treated as constants, which you can't do with other lazily initialized variable types. One could make the argument that with this solution it's possible an instance might be initialized "too soon" or "needlessly" if the same type also exposes some other static members that are accessed first, and if the runtime decided to run the type initializer at that point. But the thing is that this approach is usually not what Singleton<T> was meant to support in the first place. You'd usually have something like:

public class MyType
{
    public static MyType Instance { get; } = new();

    // Some instance members
}

And so you'd always have to go through MyTime.Instance first to access any related functionality. It's unlikely that you'd also still have some other static members there, and even then, the runtime should still be able to skip the type initializer there assuming you're not also interacting with other statically initialized fields. That'd be a relatively niche scenario for the purposes of Singleton<T> as it was originally designed (which was mostly to support eg. services into apps).

Hope this helps! 😄

[OneFingerCodingWarrior]

My confuses comes from "an instance might be initialized too soon or needlessly", and your reply do delights me "if the type has other static members, it's not the purposes Singleton designed for".

And i remember the book also state "In the beginning of this section, I mentioned that the double-check locking technique is not
that interesting. In my opinion, developers think it is cool, and they use it far more often than they should. In most scenarios, this technique actually hurts efficiency." And using language syntax is the recommended way.

Thanks for the detailed replies, it do comfort me about Lazy initialization. And in the next ten years i will stop myself from writing the double check codes😄

[OneFingerCodingWarrior]

Got it!
I just a little confused by the state "The one downside of this approach is that the type constructor is called when any member of a class is first accessed." which is conflict to the meaning of Singleton "If the application never requests the object, it never gets constructed, saving time and memory. "
I will try to understand the balance between them, and thanks for the quick reply