C# 7.x: Add initializer list to stackalloc

[RexJaeschke]

I cloned a bunch of text from array initializers, omitting the ability to have multidimensional array allocation and arrays of arrays.

A very long time after I first created this PR, I discovered that other functionality was added earlier than V7.3. Starting in V7.1, stackalloc itself can appear outside of unsafe code, provided it is used in the context of a Span or ReadOnlySpan. As a result, I smuggled into this PR (via its branch) more edits. They make stackalloc a primary operator, and almost all of the semantics of it are moved from unsafe.md to expressions.md.

[RexJaeschke]

There is one unresolved issue remaining logged on Teams: The C# standard currently states, "If there is not enough memory available to allocate a block of the given size, a System.StackOverflowException is thrown." However, this is not true. My tests show that the program terminates with the message “Stack overflow.” written to the console, and exit code -1073741571 (which might be arbitrary). My try/catch clauses for System.StackOverflowException and System.Exception are ignored. Any ideas on how I should spec the behavior I observe?

[KalleOlaviNiemitalo]

Seems like this would be invalid then:

using System;
public class C {
    public void M() {
        _ = ((Span<byte>)stackalloc byte[1])[0];
    }
}

[KalleOlaviNiemitalo]

Oh right, it is invalid in C# 7, but valid in C# 8.

[KalleOlaviNiemitalo]

The proposed wording would allow the following stackalloc_initializer because it is the second operand in a conditional_expression, yet the compiler rejects it in C# 7.

using System;
public class C {
    public void M() {
        _ = ((Span<byte>)(true ? stackalloc byte[1] : default(Span<byte>)))[0];
    }
}

[KalleOlaviNiemitalo]

assignment_operator includes compound assignment operators, so the wording would allow this as well:

using System;
public class C {
    public static C operator +(C c, Span<byte> s) { return c; }
    public static void M(C c) {
        c += stackalloc byte[1];
    }
}

But the compiler rejects it in C# 7.

[KalleOlaviNiemitalo]

If stackalloc_initializer can be used in assignment_operator or conditional_expression, then that needs some changes in the grammar too. So far, stackalloc_initializer is referenced only from local_variable_initializer.

[Nigel-Ecma]

Oh right, it is invalid in C# 7, but valid in C# 8.

C# 7 seems the wiser choice here, why is it valid in C# 8?

[Nigel-Ecma]

The proposed wording would allow the following stackalloc_initializer because it is the second operand in a conditional_expression, yet the compiler rejects it in C# 7.

using System;
public class C {
    public void M() {
        _ = ((Span<byte>)(true ? stackalloc byte[1] : default(Span<byte>)))[0];
    }
}

Was the text meant to imply “The second and third operands in a”, i.e. neither or both branches? One could imagine a reason for that restriction.

[BillWagner]

Admittedly, my head hurts now.

The previous example fails because the stackalloc is part of a "nested expression". The following variation compiles in C# 7.3:

_ = true ? stackalloc byte[1] : default(Span<byte>);

I'm asking for a definition of "nested expression". It doesn't occur in the standard, and I can't find the term used in LDM notes.

[BillWagner]

This answer turns out to simplify the PR somewhat. In C# 7.3, a stack_initializer can be used only as a local_variable_initializer. In that context, the result is T*, with an implicit conversation to Span<T> for use in safe contexts.

That means the stackalloc initializer can be used as either or both the 2nd and 3rd operands of a conditional_expression.

[KalleOlaviNiemitalo]

My try/catch clauses for System.StackOverflowException and System.Exception are ignored.

I'm not sure whether the runtime considers a stack overflow a corrupted state exception as described in HandleProcessCorruptedStateExceptionsAttribute.

[KalleOlaviNiemitalo]

Also dotnet/runtime#40302 for catchable stack overflow.

[KalleOlaviNiemitalo]

The behavior on stack overflow could be implementation-defined, constrained such that if the implementation throws a catchable exception, then it must be a StackOverflowException. An implementation that throws e.g. ThreadAbortException or OutOfMemoryException instead, and lets a C# catch clause catch this exception, would not be conforming. I think requiring implementors to document the behavior would not be too burdensome.

[Nigel-Ecma]

As @KalleOlaviNiemitalo’s comments demonstrate this needs some work.

[Nigel-Ecma]

The proposed wording would allow the following stackalloc_initializer because it is the second operand in a conditional_expression, yet the compiler rejects it in C# 7.

using System;
public class C {
    public void M() {
        _ = ((Span<byte>)(true ? stackalloc byte[1] : default(Span<byte>)))[0];
    }
}

Was the text meant to imply “The second and third operands in a”, i.e. neither or both branches? One could imagine a reason for that restriction.

[BillWagner]

One outstanding question, but I've addressed the other comments.

[BillWagner]

Admittedly, my head hurts now.

The previous example fails because the stackalloc is part of a "nested expression". The following variation compiles in C# 7.3:

_ = true ? stackalloc byte[1] : default(Span<byte>);

I'm asking for a definition of "nested expression". It doesn't occur in the standard, and I can't find the term used in LDM notes.

[BillWagner]

@jskeet

This one should be ready for a final review. I don't think we have time to add more to the agenda for tomorrow, but can we add it to the list for review / approval asynchronously between this meeting and the next?

[jskeet]

Just found this again - will review today/tomorrow.

[BillWagner]

"call stack" needs to be defined in this section.

[BillWagner]

Discussion on 5/17 meeting:

• stackalloc is an expression, with an optional initializer
• search for all uses of stackalloc to remove any remaining references to unsafe code.
• define stack in this PR
• the result of a stackalloc expression must obey the ref safety rules