Allow stackalloc Span to return from local function for local consumption

[Aniobodo]

Motivation: Modular programming, Clean code, Performance

Sample: See MethodA and its local function GetNumbers below.

Issue:
Trying to return a stack-allocated collection from a local function results in Compiler Error CS8352.
If the local function is in unsafe context, Compiler Warning CS9080 is instead displayed.

Wish: The possibility to return a stack-allocated collection from a local function, for local consumption, in safe context.

 public int MethodA(Span<char> chars)
 {
     Span<int> numbers = GetNumbers(chars);
     //Further logic and processes on the Span<int>
     return numbers[0];

     Span<int> GetNumbers(Span<char>chars)//local function
     {
         Span<int> numbers = stackalloc int[chars.Length]; //stack-allocated collection
         int nextSetPosition = 0;

         foreach (char c in chars) 
         { if (char.IsNumber(c)) numbers[nextSetPosition++] = (int)c; }
         return numbers.Slice(0, nextSetPosition);//Triggers Compiler Error CS8352
     }
 }

[NN---]

Is the suggestion for local functions only ?
Otherwise it requires cross-function analysis.

[Aniobodo]

Is the suggestion for local functions only ?

Yes, the suggestion is for local functions only.

[huoyaoyuan]

Local functions are functions. Returning stack allocated buffer out of functions is critical bug and will never really work.

Only force-inline snippet may have stack allocated buffer escaped to containing function, because they would be allocated in caller function's scope.

[Aniobodo]

Only force-inline snippet may have stack allocated buffer escaped to containing function, because they would be allocated in caller function's scope.

That could be enough but only if inlining is 100% reliable.
Is method flagged with [MethodImpl(MethodImplOptions.AggressiveInlining)] fully guaranteed to be inlined?

[NN---]

If possible. Not guaranteed.

AggressiveInlining 256
The method should be inlined if possible.
Unnecessary use of this attribute can reduce performance. The attribute might cause implementation limits to be encountered that will result in slower generated code. Always measure performance to ensure it's helpful to apply this attribute.

[Aniobodo]

If possible. Not guaranteed.

AggressiveInlining 256 The method should be inlined if possible. Unnecessary use of this attribute can reduce performance. The attribute might cause implementation limits to be encountered that will result in slower generated code. Always measure performance to ensure it's helpful to apply this attribute.

That used to be the case until now.
.NET 9 made some promises: dotnet/runtime#93069
But I have not be able to find any latest information on the reliability of [MethodImpl(MethodImplOptions.AggressiveInlining)] .

[NN---]

You cannot guarantee this. JIT has own decisions when it is good to inline or not for the current platform the program runs.
In order to guarantee, you need a compiler error if this cannot be inlined.

[huoyaoyuan]

Currently, the JIT will always refuse to inline cases like exception handling block, because it will require much more complex transforms.

It also refuses to inline when it encounters stackalloc. Thus it must require a new concept of snippet that's inlined by C# compiler.

[jaredpar]

The stackalloc operation allocates memory that is only valid for the currently executing method. That is true no matter what type of method this is, the runtime doesn't differentiate or even understand local vs. non-local. In order for this proposal to be viable either:

1. The compiler would need to inline local methods to some extent.
2. The runtime would need to provide a new primitive like stackalloc that could survive for more than the current method.

The better pattern here is to have the calling method allocate and provide the buffer.

[Aniobodo]

The better pattern here is to have the calling method allocate and provide the buffer.

That is currently the only option, but certainly not the best solution when the size of the buffer is to be determined in the local method itself.

[toupswork]

I am not disagreeing with you. I noticed one difference is that often the compiler-generated class for scope in the local function can be allocated on the stack if the the escape analysis shows it's safe

[Aniobodo]

.NET 9 introduces some enforcement of the struct size of inline-array: https://learn.microsoft.com/en-us/dotnet/core/compatibility/core-libraries/9.0/inlinearray-size

Granted that inline-array is different from inline-method, but the similarity here is the size dependency.
Since the success of [MethodImpl(MethodImplOptions.AggressiveInlining)] depends (among other factors) on the IL size of the flagged method, maybe some enforcement on the size of an aggressiveInlined-method can be introduced.

[huoyaoyuan]

Aggresive inline is not force inline. stackalloc disallows inlining totally. Allowing such inlining can cause problems when used in a loop.

Granted that inline-array is different from inline-method, but the similarity here is the size dependency.

I can't see any relationship between InlineArray and inline functions. They are totally unrelated things. Returning an InlineArray from function is very expensive that requires copying the whole struct.

[Aniobodo]

stackalloc disallows inlining totally.

That's a new information.

[ufcpp]

dotnet/runtime#52065

[BlinD-HuNTeR]

This topic has become a whole discussion about method inlining, but that's not really the point.
What you are asking for is to have stackalloc cross method boundaries, which is exactly what stackalloc is not meant for.

Even if you say "just for local functions", the point is, there's no such thing as a local function: it gets compiled as a regular method with an unspeakable name. And in some cases, the compiler also synthesizes an invisible struct with the captured variables, and passes that struct by ref to the "local method".

To implement your proposal, it would be required that the compiler also detects any usage of stackalloc, then move those allocations to the containing method, and introduce an invisible parameter to pass that buffer.

Except, that you can just do that yourself: instead of performing stackalloc inside the local method, just add an extra Span<int> parameter to it. And then you can call the method like Span<int> numbers = GetNumbers(chars, stackalloc int[chars.Length]);