Same here, alignment is passed to another method GenerateRow, so it's not safe to use stackalloc here.

It looks to me that GenerateRow uses alignment before this function returns and therefore should be safe.
Additionally, if the compiler can detect this condition as the blog suggests (per @iSazonov's comment), then we should rely on the compiler's analysis unless we find the compiler's analysis deficient.

I should add that Span<T> is managed code.
Before C# 7.2 we have some protections for Span<T> only in runtime.
Since C# 7.2 Roslyn does additional checks at compile time and exclude unapproved usage.

I understand the C# compiler can catch an issue like that, but the person who is facing that compilation error might not be the one who used stackalloc in the first place.

Imagine I will change the implementation of GenerateRow at some later time and my change would actually cause the unsafe reference to happen, and that means I will see the compilation error but have no idea why it fails. After finally figuring out why this could happen, I will need to search all callers of this methods and maybe the callers of those callers and so on to find "Ah, there is a stackalloc here".

Therefore, I think we should have a guideline about when to use stackalloc, so things can be less complex.

I agree that the error might be confusing to another contributor.

If we have guidance on when span and stackalloc can be used it should be clear and easy to follow.

@SteveL-MSFT They don't support Alpine in 2.0 and support in 2.1 Prview1 and perhaps in Preview2

So in your example return MethodTwo(arr); will throw an error in any case (Span and Slice).

I think you didn't get my point.

What I try to point out is the use of stackalloc might make future changes raise compilation error at an unexpected location.

Use the same example, say initially methods MethodOne and MethodTwo looked like this:

Span<int> MethodOne(...) {
    int[] arr = new int[len];
    return MethodTwo(arr); // <-- return the span returned from another method
}

Span<int> MethodTwo(Span<int> span, ...) {
    int[] array = new int[length];
    ...
    return array.slice(...); // <-- return a slice of an array
}

So when you changed to use stackalloc in MethodOne, it would compiles fine, and the methods became:

Span<int> MethodOne(...) {
    Span<int> arr = stackalloc int[len];
    return MethodTwo(arr); // <-- return the span returned from another method
}

Span<int> MethodTwo(Span<int> span, ...) {
    int[] array = new int[length];
    ...
    return array.slice(...); // <-- return a slice of an array
}

Then later, another contributor changes MethodTwo to return a sclice of the pass-in argument span like this:

Span<int> MethodTwo(Span<int> span, ...) {
    ....
    return span.Slice(...); // <-- return a slice of the passed-in span
}

And then the contributor will see the unexpected compilation error from MethodOne.

This is the situation that I want to avoid with some coding guidelines. So what should be the guideline in this situation? Should it be:

• Do not return a slice of a passed-in span argument in a method? (attempt to prevent this situation from MehtodTwo)
• Or, do not directly return a span result returned from another method when you pass in stack memory as an argument to that method? (attempt to prevent this situation from MethodOne)

Hope I made myself clear this time :)

I see your point. I believe we could compare this with changing in a base class - we can catch tons compilation errors in derived classes - this is the same situation. Another example is a changing in a helper class - we can get compilation errors in each call point.
And it seems like your example is too incredible if we try to imagine a real situation - such a change in the code completely changes its contract as if Array. Sort would start to do a clone-then-sort. By the way, in the latter case we may get an unpredictable run-time error or nothing worse. So Span gives even more reliable code.

I think this is something that we will have to get used to. It is a new and very welcome addition to the .net runtime, and we as developers need to learn to troubleshoot the issues that arises.
I say let the compilation error happen, and add answers to StackOverflow on how to resolve and understand them.

If we use a threshold to select stackalloc vs new we could use one of two patterns
https://github.com/dotnet/corefx/blob/58af9adc8c6c70df4b7fd158c984508d96baca59/src/Common/src/System/Security/Cryptography/ECDiffieHellmanOpenSsl.Derive.cs#L165
https://github.com/dotnet/corefx/blob/8b70122cef4a165def5224001b38f10967619669/src/Common/src/CoreLib/System/Globalization/CompareInfo.Windows.cs#L141

Also I found interesting sample https://github.com/dotnet/corefx/blob/fcfb556ebf99ed551c02d0146c805e792b264cf2/src/System.IO.FileSystem/src/System/IO/Enumeration/FileSystemName.cs#L197 - using Span<int> temp = stackalloc int[0]; disable expose outside of the method.