Collection expressions: use inline array for span argument when the argument cannot escape

[cston]

Split out from #69291.

Relates to test plan #66418

[Sergio0694]

When using this on a runtime without [InlineArray], would this show an error or silently allocate an array? 🤔

[cston]

When using this on a runtime without [InlineArray], would this show an error or silently allocate an array?

The proposal implemented here is to allocate an array on heap when the runtime does not support inline arrays.

[alrz]

(unrelated) I'm going to sound like a broken record but didn't this ended up being an expression? Just asking because this pattern is already present in list-patterns except that this doesn't need explicit handling in the binder since the parser would never produce such node anywhere else. I'm willing to do the work to make it so if there's timing concerns. Thanks!

[CyrusNajmabadi]

I'm not sure what you're asking here.

"but didn't this ended up being an expression?"

What are you referring to here?

[alrz]

Sorry, I was asking about the syntax model for collection expressions and whether or not CollectionElementSyntax needs to exist to distinguish between spread and expression elements. Would it make sense to consider a SpreadExpression here? As mentioned above I don't think this involves any additional complexity in the parser.

[CyrusNajmabadi]

I'm not seeing the value in a SpreadExpression. We'd also then need a KeyValueExpression. Neither of these could show up anywhere else, so i'm not sure why that would be a good thing. Conversely, having specific element types for a list matches what we do elsewhere, and provides clear informatino as to the strong types, and expected shapes, one would expect when processing these lists.

[CyrusNajmabadi]

NOte: further things might be a construct like if (x) y allowed as a collection-expression element. Making expressions out of all of these things (even though they would only be viable in one parent) is not a good thing IMO.

[cston]

Replaced by #69412.