A danger of being too clever
A friend of mine applied for a job and received a test task to write an application that should be using a singleton. He decided to follow the fourth approach among the ones listed here (“not quite as lazy, but thread-safe without using locks”). I also think that this is most elegant although .NET-specific singleton implementation. Yes, it is not as lazy as other alternatives, but it is lock-free, and I’d always go for minimalistic code first and make it more complex later based on additional requirements.
Unfortunately, my friend’s suggestion has been rejected. And one of the reasons: “not thread-safe singleton”. I guess the guy who verified the code was looking for locks and refused to believe that code can be made thread-safe without using them. The suggested solution was just too clever for him.
So my friend was not hired, but I said to him that he should not regret. I am not sure I’d personally enjoy working for somebody so fixated on his own decisions. Still there may be a lesson learned from such failure. Perhaps when presenting our solutions to others we should evaluate if they can be unexpected for those who is going to review them, and in case of such risk add a brief explanation about why we made our choice and what other alternatives could be considered.