I understand pointers and the rare need to use them in C# code. My question is: what is the reasoning behind having to explicitly state \"unsafe\" in a block of code. Additi
Actually the CLR makes no requirements at all about an /unsafe switch or keyword. In fact, C++/CLI (the C++ language that runs under the CLR) has no such /unsafe switch, and pointers can be used freely on the CLR.
So I would rephrase your question as "Why does C# require the use of /unsafe before pointers can be used?" And the answer to that question is as stated in other answers given here: to help the user make a conscious decision to lose the ability to run in anything less than Full Trust mode on the CLR. C++ virtually always requires Full Trust on the CLR, and C# can whenever you call code that requires Full Trust, or whenever you use pointers.
Think about it from the opposite point of view: because it's not marked unsafe, you can infer that most code is "safe" by default. So what does it mean to be "safe"? For .Net code, this includes (but may not be limited to):
Any time you use pointers you have the chance to break any of those guarantees. Therefore marking code as unsafe gives up those protections.
Nurturing good habits & security. Whenever you use an unsafe block in an assembly, a NativeCode permission will be demanded from the stack. This could of course be done implicitly, but couldn't we also just remove the private keyword completely? I think it's good to force developers to specifically require unsafe code before they can use it.