Proposal: spanalloc

[RenderMichael]

One of the unfortunate things about stackalloc is it's natural type being T*, so if we want a Span<T> we need to explicitly declare the type instead of using var.

I propose spanalloc, exactly the same as stackalloc but with a natural type of Span<T>.

[alexrp]

var span = (stackalloc byte[1024]); // typed as Span<byte>

Still not great, but you do get to use var.

[RenderMichael]

That's neat, I did not know that. With this there's no way spanalloc gets any traction, that's the end of the proposal

[colejohnson66]

How/why does wrapping it in parenthesis fix it?

[msedi]

@corivera @alexrp . Yes, I would also be interested why the parenthesis does this.

[DaZombieKiller]

How/why does wrapping it in parenthesis fix it?

Previously you could only use stackalloc on its own, not as part of a more complex expression. When support for stackalloc in complex expressions was added, a decision was made to have such stackallocs always result in a Span<T> instead of a T*. So when you write (stackalloc T[n]) instead of stackalloc T[n], you have technically made it part of a complex expression, thus you get a Span<T>.

[RikkiGibson]

Related to dotnet/runtime#52065. If runtime introduces a special API which simply stack-allocates a span, we probably wouldn't add a new syntax just for creation here. Though the implementation of collection literals (#5354) may also call into that API as appropriate.

[ufcpp]

If a new grammar is to be added for this purpose, I would prefer suffixes or prefixes of collection literals.

var list = [ 1, 2, 3 ]; // List<int>
var span = [ 1, 2, 3 ]s; // Span<int>

[jnm2]

I'd prefer var span = stackalloc [1, 2, 3];.

[geekley]

Why can't var a = stackalloc byte[1024]; (without parentheses) resolve to Span instead of pointer when used on a safe context? It's better than having CS0214 error. And if you say "that would be inconsistent", to me it would be less inconsistent than parenthesis having different behavior.

[DaZombieKiller]

Perhaps the compiler could treat a in var a = stackalloc T[n]; as an unspeakable type that is implicitly convertible to both T* and Span<T>? There are probably a number of issues associated with doing that, though.

[jnm2]

I don't think the language has ever changed the type of a var from version to version. It seems like a serious breaking change.
(Edit: never mind. forgot the "in safe contexts" part when coming back to this)

[RenderMichael]

It would be a breaking change on paper, but it would break exactly 0 scenarios since T* is illegal outside of unsafe.

That said, it would make a different scenario untenable: imagine you’re working in a safe method, then you have to do something unsafe so you annotate the method as unsafe. Suddenly, a var in a different part of the method changes meaning. That scenario doesn’t sound like something the LDM would ever accept.

[DaZombieKiller]

What I'm proposing would not be a breaking change, it would simply make some code that is invalid today valid:

var a = stackalloc int[8]; // int*
var b = (int*)a; // okay
var c = (Span<int>)a; // error

With what I suggested:

var a = stackalloc int[8]; // "fake" type that only exists at compile-time
var b = (int*)a; // okay
var c = (Span<int>)a; // okay

The real issue I see is just that this is covering a pretty niche case, and if you want a Span<T> you can simply wrap the stackalloc in parentheses today. As a result I'm not super convinced that the value it adds would justify the effort to spec and implement it.

[333fred]

It would be a breaking change on paper, but it would break exactly 0 scenarios since T* is illegal outside of unsafe.

That said, it would make a different scenario untenable: imagine you’re working in a safe method, then you have to do something unsafe so you annotate the method as unsafe. Suddenly, a var in a different part of the method changes meaning. That scenario doesn’t sound like something the LDM would ever accept.

Well said, this is my immediate objection to such a change.

[colejohnson66]

I know it’s a personal decision, but if one used the actual types instead of var, this wouldn’t be a problem. What’s wrong with Span<byte> a = stackalloc[x]? Why would we need new syntax to resolve a non-issue?

[RenderMichael]

Personally I use var when writing an expression, then use the IDE to convert that to the real type. It's a developer experience thing for me