How about allowing Span of stackalloc to escape stack without actually escaping stack using compiler hacks

[Xyncgas]

In any cases you are returning a span of stack allocated memory then use that memory in another function or in an imperative way with a variable, pretend that you've passed in the client that's using this memory as a function so you can access the stack allocated memory without it actually escaping the stack.

This makes no changes to how codes are written, but imagine System.Text.Encoding.UTF8.GetBytes(string) now returns Span that's not representing a region of memory in the heap therefore no allocation, which is impossible, unless we inline this function or we pass in a function that takes a span then we can use this span, so let's make the compiler to do this

This way, we will eliminate any memory being created in the heap when they are not too big for the stack, and with classes like Span people can still put the memory to heap by calling ToArray() for using the memory in another occasion, it's just that this would happen a lot less because you don't have to do it before returning stack allocated memory now

[Clockwork-Muse]

I'm assuming you're suggesting that something like:

public byte[] GetBytes(string input)
{
    // .... some code
    return someByteArray;
}

... is being automagically converted to (in this case existing):

public int GetBytes(ReadOnlySpan<char> input, Span<byte> output)
{
    // whatever
}

You can't, not in the general case. First, this requires deep introspection and rewriting of both the callee and the caller (remember, the caller would be required to pass in the destination span), which is maybe doable for some simple cases, but fails in a large number of edge cases. If the caller returns that byte array, the transformation can't be made. If the array element is a reference type (a class), the transformation can't be made.
(well, okay, you could, but doing so would also require rewriting the next caller, so this gets messy fast).

This way, we will eliminate any memory being created in the heap when they are not too big for the stack

You've picked possibly the worst method to use an example if this is one of your justifications. GetBytes(...) can return results vastly larger than would fit on the stack, and in most cases the size of the return can't be known until runtime based on input coming over an untrusted socket. Using the existing span-equivalent method requires multiple calls where the version that returns an array only needs to be called once - there isn't a (good) way for the compiler to know whether it's safe to make that sort of transformation, so it can't.

[Xyncgas]

It's possible to use stack allocated span for decoding encoded string, meanwhile how about I pass in a function to access the stack allocated memory instead, and I would put more faith in not worrying about having to know about the length to allocate memory because it sounds very easy to solve while is NOT the reason blocking this idea

[Clockwork-Muse]

APIs like that can be written, yes. For example, Create<TState>(int length, TState state, System.Buffers.SpanAction<char,TState> action)
(yes yes, it requires you pass in a destination length, but depending on the actual use case there would be ways to derive this automatically)
Do note this method isn't actually using stalloc-ed memory inside (since it's going to need to return it when the string is returned), but this is the sort of signature you're looking at.

But... you can't get the compiler to automagically create this for you. It's an API design decision. And it wholly depends on what your final data destination looks like; even if in some cases you can use a stackalloc-ed piece of memory, it's not going to matter if you have to eventually write to a heap-allocated array, or something.
Keep in mind, too, that generally the stack is limited to like 1MB or something (or lower - it's configurable at runtime). So if you could do something like this automatically you'd likely chew through the stack pretty quickly. stackalloc is really intended to be for small temporary arrays (with the size preferably known at compile time). A transformation like this would likely make them longer lived.

---

So... what is it you're actually doing that you're asking for this?

[Xyncgas]

If we let Span created from stack allocated memory be return-able, the compiler would rewire the codes that use the returned Span as if it was a function passed in as an argument to use the stack allocated memory.

If you are authoring such a function that returns a byte array, the only difference is that now you can optionally add a code path for creating this array in stack if you know the data structure and the number of elements are small enough, then you are now able to return this array that's stack allocated without ever putting it to heap

Which kinda is big deal if you ask me, for we are allowing people to write these kinds of functions very easily just by simply changing the return type from say byte[] to Span and adding a branch of stack allocation, without changing so much of the code to take a function in as argument because that's done by the compiler / language support / dot net RT by allowing returning stack allocated Span

[Clockwork-Muse]

If we let Span created from stack allocated memory be return-able, the compiler would rewire the codes that use the returned Span as if it was a function passed in as an argument to use the stack allocated memory.

This is, in a few cases, theoretically possible.
The problem is that it doesn't gain you much, because all it really does is rearrange some elements of the method signature. Too, in any case where the Span would be dynamically sized you actually need to return two values - the Span and an int count size, which the calling method actually has to be written to handle. It's just far easier - and better practice - to explicitly write the proper Span-taking version.

If you are authoring such a function that returns a byte array, the only difference is that now you can optionally add a code path for creating this array in stack if you know the data structure and the number of elements are small enough, then you are now able to return this array that's stack allocated without ever putting it to heap

Nope. The compiler would have to rewire the caller to do this, because you have to pass the Span in. The net effect would probably be inlining the entire callee if the array size was in any way dynamic, which would be problematic in its own right.

[Xyncgas]

in any case where the Span would be dynamically sized you actually need to return two values - the Span and an int count size

The Span is just a span, you can enumerate over it no matter what size it is, also it has a length property that says how many elements are inside

If you are going to inline everything so be it, eventually if people wants to break them up they can write more functions that doesn't use Span inside, or we can do our best effort to inline and at some point we might be inlining the calling method into ourselves or ourselves into other places but that's fine we've eliminated a lot of heap allocations for people now not only have the ability to allocate memory in stack but also returning them

In a functional world, this would be easily possible just like we used call backs everywhere before co-routine / await, and we can convert object oriented code to functional codes just need to put some brain juice

For example if you are the function then the byte[] you are returning is your arm handing out stuffs to someone, if someone can take that someone and put them in their mouths then the compiler can just let people return stack allocated bytes

[Clockwork-Muse]

The Span is just a span, you can enumerate over it no matter what size it is, also it has a length property that says how many elements are inside

No, the problem is that in most cases where a Span is passed as a parameter, it doesn't end up filled, and is instead smaller than the available space. This is a plausible outcome of any such rewriting (ie, anything where the called method is reading bytes from a socket or file). That's where the size/count parameter comes from.

If you are going to inline everything so be it, eventually if people wants to break them up they can write more functions that doesn't use Span inside

Even ignoring Span issues, this is a terrible optimization strategy....

In a functional world, this would be easily possible just like we used call backs everywhere before co-routine / await, and we can convert object oriented code to functional codes just need to put some brain juice

There's nothing inherently special about functional languages or styles in this area, the problem is more of a hardware/calling convention one.

then the compiler can just let people return stack allocated bytes

You can't "return" stack allocated anything, especially anything dynamically sized, because doing so would require that you dynamically reorder the stack at runtime (and probably only allow one dynamically sized thing). Which would be an optimization and security problem. And for this to be really useful you'd need multiple levels of callers to do this, which would mean you'd have to copy parts of the stack as each level is unwound, which would possibly eliminate most of the savings.

[Xyncgas]

The only reason something is dynamic sized is the developer's refusal to decide how many candles to light for their birthday cake
If a method can return a byte[] they can return a span of that byte[], it's just that this span can now also be of stack allocated memory, which is possible imo to automaticaly wire codes to do by the compiler

[Clockwork-Muse]

Okay, I'm being a little silly, and not thinking things through.

Yes, you can return things on the stack, usually by copying them.

The problem with this, for Span, is that it only contains a reference, and not the actual data. Which means the reference would point to data that has been dereferenced.

[Xyncgas]

We can easily return a integer or a struct, but to return stack allocated memory we can convert them to value types or we have to put them on the heap because once we leave the stack the memory is gone that's why Span contains a pointer that doesn't point to the already gone stack allocated bytes because the compiler won't allow it because the stack is gone once the function is return

But hey man it's a possibility, to use the stack allocated memory while we are inside the function before it's returned, therefore rewiring the codes that's going to use the returned byte[] in the kinds of function we have today to put them inside the function's stack of which was returning this stack allocated memory can be a way to do it

[Xyncgas]

I realized I can return stack allocated memory by using inline function in F# which is a different inlining method than C# in which it behaves like a macro