Proposal: Allow braceless fixed statement -> get rid of nesting

[NiTiSon]

Now:

fixed(byte* pValue = ...)
{
    some_low_level_api_function(pValue);
}

fixed(byte* pValue1 = ..., pValue2 = ...)
{
    some_low_level_api_function2(pValue1, pValue2);
}

Braceless:

fixed byte* pValue = "..."u8;
some_low_level_api_function(pValue);

fixed byte* pValue1 = ..., pValue2 = ...;
some_low_level_api_function2(pValue1, pValue2);

[colejohnson66]

While I'm not personally opposed to this, I think this would fall under the same arguments as "brace-less" lock. The LDM's response has consistently been: "braces ensure the scope is as small as possible".

[tannergooding]

There notably is. C# emits IL to null out the pin slot, for narrower scopes, which tells the JIT the member is no longer

However, this is also similar in nature to using statements and there are plenty of reasons why reducing nesting is desirable as well, such as when the scope is already clear or for the whole method (both of which are common)

[colejohnson66]

Yes, that's every requests' argument: "it reduces nesting". But the LDM has held firm that "reduce your scope, so braces are mandated" when it comes to lock. Why would reducing nesting of fixed be any different?

Again: I'm not opposed to it. I'm just trying to understand the logic.

[tannergooding]

I'd guess it likely depends on the declaration type and potential impact.

lock has some very nasty potential to be "worst case" in such scenarios. fixed does not and using is a bit in between.

Ultimately it's up to LDM

[colejohnson66]

Fair. The worst fixed can do is hold a pin for longer than necessary. But an overlong lock can lead to bad performance from waiting threads.

[CyrusNajmabadi]

I don't know if htere is appetite at all for this sort of area.

1. it is for unsafe code. Something we think should be a last resort, and whihc we want to continually move people away from with better, safe, language approaches for thsi sort of thing.
2. it's for a feature that is used staggeringly less than 'using'.

[333fred]

Duplicate of #2186.