Extend eligible params types to array generic interfaces and span

[alrz]

Championed issues: dotnet/csharplang#179, dotnet/csharplang#1757

open questions:

• do we want to forbid conflicting params overloads with identical element types? (otherwise all overloads would be always applicable in the expanded form and therefore ambiguous; note: the compiler wouldn't give ambiguous result for that case "for free", if we permit that, the overload resolution should be adjusted accordingly) -- this is now implemented in this prototype

Note: this is based on top of nested-stackalloc for spilling.

[alrz]

I'd like to add params Span<T> dotnet/csharplang#535 to the mix but I think it makes sense to wait for "stackalloc initilaizers" dotnet/csharplang#1122 first to reuse its lowering.

[alrz]

stackalloc initializers is here: #24249. we should be able to add params Span support on top of that.

[jcouv]

Tagging @gafter since he's the champion for that language feature.

[jcouv]

Sorry for the delay. I'll queue this for discussion in LDM.
The main open question is what set of types should be recognized for this scenario.

[alrz]

Since the majority of the work has been done as part of pattern-matching (spilling) and stackalloc init (codegen), this has became a rather smallish change now. @jcouv Could you please push this for the next LDM this month? Please let me know if a proposal is needed in csharplang. Thanks.

[gafter]

What happens if you call a params Spam method in a loop? Stack overflow? If so, that is not what we want.

[alrz]

@gafter As you said in the other thread, in a loop we can reuse the same Span if all elements are constants, otherwise we could fallback to Span(T[]) - I think we could still emit optimal code most of the time.

Edit: actually, there'd be no reason to fallback to array for this. we capture stackalloc pointer and only initialize it in the loop body. further optimizations are possible, e.g. initialize once if all constant, etc.

[gafter]

All arguments being constants is rare. If the caller usually has to allocate an array, the feature seems less valuable.

[alrz]

I'm experimenting with initializing a sized struct (ditching off stackalloc completely)

// assuming T is a sized value type
Sized_Struct s;
T* a = (T*)&s;
a[0] = e1;
a[1] = e2;
M(new Span<T>(a, sizeof(T) * 2));

Unlike stackalloc, this won't throw in a loop. (note: stackalloc init optimizations will apply here as well).

Is that something that we could rely on?

[alrz]

I've done a preliminary implementation for the "sized struct" to avoid stack overflow with stackalloc at alrz@aaed6cd. Currently it uses "ImplementationDetails" infra to generate the type, but I think we should extract that part into an standalone component (ImplementationDetails is disabled on debug builds).

While it is a limitation in practice, I think it covers most of the use cases that could possibly be optimized. A warning may be desirable where the underlying type is definitely not sized, except for generics because they could get a size after type substitution.

[alrz]

I see params span is triaged for 9.0. Do we want params IEnumerable for now or it's postponed altogether? (we'll probably need to adjust VB for new params types anyways)

[gafter]

I see params span is triaged for 9.0. Do we want params IEnumerable for now or it's postponed altogether? (we'll probably need to adjust VB for new params types anyways)

We're done with C# 8 and about to start triaging features for future versions. We have not done that yet so we don't know.

[alrz]

given the new params Span design (https://github.com/dotnet/csharplang/blob/master/proposals/format.md) this prototype is severely out of date. params IEnumerable support could be trivially added afterwards on top of that. Closing.