Try Unsafe block

[TheBrambleShark]

Similarly to how we can stack using blocks, I would like to see us be able to stack try and unsafe.

E.g.:

// Old
try
{
    unsafe
    {
        // Do stuff in unsafe context
    }
}

// New
// We can keep them on one line for legibility
try unsafe
{
    // Do stuff in unsafe context
}

Use-case
Sometimes, especially in the case of try-finally blocks, the entire try clause is unsafe context. For instance, here's some code I put together in learning how to use Span:

public Password(SecureString password)
{
    IntPtr valuePtr = IntPtr.Zero;
    try
    {
        valuePtr = Marshal.SecureStringToGlobalAllocUnicode(password);
        unsafe
        {
            _password = new Span<char>(valuePtr.ToPointer(), password.Length);
        }
    }
    finally
    {
        Marshal.ZeroFreeGlobalAllocUnicode(valuePtr);
    }
}

In this case, the marshal operation could be placed in the unsafe block without issue, and thus the entire try clause could be made unsafe. (Forgive me for using SecureString, the point was learning how to use low-level stuff like marshaling and span, so I went all-in. This is not production code).

I felt try unsafe should be the proper order since it reads somewhat like "try [this] unsafe [action]," though if unsafe try seems better due to keyword ranking or whatever other reasons, I'd love to hear thoughts.

[GrabYourPitchforks]

Generally speaking, when you're dealing with pointers and other native resources within the context of a try block, wouldn't you also need to access those same pointers / resources in a finally block? So you'd almost certainly need the pattern try unsafe { /* ... */ } finally unsafe { /* ... */ }?

In your particular example the use of Marshal and IntPtr is somewhat masking the unsafeness of the operation, but more traditional p/invoke code doesn't tend to mix-and-match between IntPtr and void*. They'd generally stick with one of IntPtr (which doesn't require unsafe) or void* (which does require unsafe) unless they're performing advanced type interop scenarios.

[HaloFour]

Why does this need a language change at all? You can already avoid the extra indentation by putting the unsafe modifier on the method, which is less verbose than both forms of your use case. Otherwise I'm of the opinion that unsafe code should stick out and also shouldn't be made easier to do. Are we also going to need unsafe if and unsafe while and unsafe foreach and every other permutation?

[alrz]

The syntax unsafe <embedded-statement> will make all those possible.

I think checked, try, catch and finally could also be relaxed the same way.

edit: checked statement has an expression counterpart, so it'll be probably ambiguous.

[tannergooding]

You can already avoid the extra indentation by putting the unsafe modifier on the method

Just wanted to point out that this isn't possible in async contexts and you explicitly have to add unsafe nesting at multiple intervals. It isn't necessarily common, but it can be a pain when you encounter it.