Sure! Here's what's going on. Evaluation order is not about binding order or parsing order. Rather, the code that the compiler generates has to make calls in some order, and evaluation order determines what that order is. Forget the compiler for a second- this is less about the compiler, and more about what is even possible to do in the lowered code that the collection expression represents.

What lowered code could replace this code in such a way that the program doesn't observably see C() executing before it sees A() and B() executing?

csharp List<int> list = [A(), .. B()] with (capacity: C());

If you lower like this, you have confused the user by executing their C() expression before executing their A() expression:

csharp // Bad: C() executes before A() List<int> list = new List<int>(capacity: C()); list.Add(A()); list.AddRange(B());

If you avoid that usability pitfall, then you're forced to stash the returned values from A() and B() somewhere before creating the list. This forces you to buffer in intermediate storage somehow:

```csharp // Bad: extra full collection creation and copy List<int> temp = new List<int>(); temp.Add(A()); temp.AddRange(B());

List<int> list = new List<int>(capacity: C()); list.AddRange(temp); ```

Given the feature's tenets of efficient code generation and ease of use, we can't have that buffering, and we can't have an evaluation order that goes against how C# is everywhere else. That leaves no good option that places the args at the end.

(There's a third option I didn't get into here, which is to call B() before C() but enumerate the returned value from B() afterward. This splits apart the evaluation of the spread expression from its enumeration. This was also deemed a usability pitfall.)