Champion "Permit stackalloc in nested expressions" (16.3, Core 3)

[gafter]

• Proposal added
• Discussed in LDM
• Decision in LDM
• Finalized (done, rejected, inactive)
• Spec'ed

The Roslyn compilers have the machinery to rewrite expressions so that they occur in non-nested contexts if necessary. We use that mechanism as part of the translation of await. We could use it to easily permit stackalloc in contexts where they are not simply the initializer of a local declaration.

The specification would be something like:

Stack allocation

We modify the section Stack allocation of the C# language specification to relax the places when a stackalloc expression may appear. We delete

local_variable_initializer_unsafe
    : stackalloc_initializer
    ;

stackalloc_initializer
    : 'stackalloc' unmanaged_type '[' expression ']'
    ;

and replace them with one production in which the left-hand-side is primary_no_array_creation_expression and the right-hand-side is the stackalloc expression.

primary_no_array_creation_expression
    : 'stackalloc' unmanaged_type '[' expression ']'
    ;

Other changes to the stackalloc expression that occurred in C# 7.3 should be reflected as well.

[alrz]

this would be the groundwork for a hypothetical params Span<T> feature. We will need to spill the stack before we emit stackalloc for a params Span<T>.

[gafter]

@alrz I think params Span<T> would be inherently dangerous. Just using such an API inside a loop would likely cause stack overflow. That makes me doubt we'd add it as a language feature.

[gafter]

On second thought, we could reuse the same Span for the same call point in the code in subsequent iterations of the loop.