stackalloc can initialize a ROS

[BillWagner]

The ReadOnlySpan<T> is also a valid type for a stackalloc in safe code.

Found while investigating #1232

While this doesn't address #1232, it was an omission.

[KalleOlaviNiemitalo]

I don't think this change is right.

1. Consider the following (SharpLab):

   using System;
   public class C {
       public void M() {
           C c = stackalloc int[1];
       }
       public static implicit operator C(Span<int> x) => new C();
   }

   If ReadOnlySpan<T> has a similar implicit conversion operator from Span<T>, then that can be used for the initialization, and the type of the stackalloc expression need not be ReadOnlySpan<T> directly.

2. If the type of stackalloc expression could be either Span<T> or ReadOnlySpan<T>, then you'd likely need a disambiguation rule for when both types are feasible, e.g. when calling an overloaded or generic method.

[Nigel-Ecma]

I think @KalleOlaviNiemitalo is correct here, it looks like Span<T> has an implicit conversion to ReadOnlySpan<T>. If Span is changed to ReadOnlySpan in the example it fails as it requires two implicit conversions to be inserted, but use an intermediate variable and it is valid as each line only requires the insertion of one conversion:

    public void M()
    {
        ReadOnlySpan<int> x = stackalloc int[1];
        C c = x;
    }

[KalleOlaviNiemitalo]

The implicit conversion is required by C.3 Standard Library Types not defined in ISO/IEC 23271:

csharpstandard/standard/standard-library.md

Lines 578 to 583 in a0995e5

	public readonly ref struct Span<T>
	{
	public int Length { get; }
	public ref T this[int index] { get; }
	public static implicit operator ReadOnlySpan<T>(Span<T> span);
	}

So I don't think any normative text for stackalloc should be changed for this. A note could be added though.

C.3 seems to be the only mention of ReadOnlySpan<> in the spec. AFAICT the semantics of the implicit conversion are unspecified and a conforming implementation could make it always return default(ReadOnlySpan<T>). Users would be unlikely to choose such an implementation though. But any note added in the stackalloc description should be carefully written not to claim any semantics that the standard does not actually require.