[Proposal] fixed expression

[MkazemAkhgary]

this proposal is derived from #1040 I thought maybe its better to have separate thread for this. since its separate feature on its own.

allow fixed statement to be used as expression.

{
    int* ptr = fixed(&managedObject.SomeField);
    // while in current block, managedObject is fixed
}
// managedObject is no longer fixed

I thought the operator & could be omitted, because fixed is already going to take pointer. but I guess it can cause ambiguity in pointer to pointer scenarios.

One usage you can see in issue #1040 . other than that this can also save 2 lines, avoid extra block when using fixed as expression.

[tannergooding]

I would prefer a syntax of fixed int* ptr = &managedObject.SomeField

This is also very similar to #114 and dotnet/roslyn#5881, just with fixed statements, rather than using statements. -- There were several comments about expanding those proposal to cover fixed, lock, etc as well.

[MkazemAkhgary]

@tannergooding please see my previous proposal, I guess fixed int* syntax will limit this feature to be used by stackalloc in single statement.

[tannergooding]

@MkazemAkhgary, I was reading it but still don't understand why fixed int* syntax would limit it to be only usable by stackalloc.

fixed int* = &myStruct.myField should be uniquely distinguishable from fixed int* = stackalloc int[length]. Additionally, you should never need fixed stackalloc, since all stackallocs are implicitly fixed.

[MkazemAkhgary]

I see that makes sense. so in conclusion such statement would be valid to compile.

fixed int* ptr = cond ? stackalloc int[length] : &(new int[length])[0];

How ever, since stackalloc is implicitly fixed, wouldn't this cause compile time error pointer is already fixed?

But I get your point, it should also make sense to have fixed explicitly for stackalloc.

fixed int* ptr = stackalloc int[length]; // fixed can be omitted.

@tannergooding

[MkazemAkhgary]

@tannergooding here is main challenge. how should fixed ptr be treated in conjunction with normal ptr and implicitly fixed ptr?

fixed int* fixedPtr = &myStruct.myField;
fixed int* fixedPtr2 = fixedPtr; // error pointer is already fixed?

int* ptr = somePointer; // just some pointer (unknown if its fixed or not)
fixed int* fixedPtr3 = ptr ; // error can not assign non-fixed pointer to fixed pointer?

int* implicitFixedPtr = stackalloc int[10];
fixed int* fixedPtr4 = implicitFixedPtr; // if ptr to fixed-ptr is error this becomes impossible :(
fixed int* explicitFixedPtr = fixed stackalloc int[10]; // what about this one?

I get your point that stackalloc array is implicitly fixed, but for Semantic Analysis phase of compiler, fixed ptr should not be (or better not to be) assignable to and from normal ptr.

so fixed stackalloc maybe needed in order to solve ambiguity.

[tannergooding]

It should be entirely possible for the compiler to relax the fixing an already fixed expression requirement (as far as I know, there is no restriction at the IL level here).