Proposal: Array Allocation and Initialization with [..] and Range-Value Fill Syntax

[TizzyT566]

Summary

Introduce concise syntax for array allocation and initialization using range literals, inspired by collection expressions and slicing:

int[] arr = [..128];               // new int[128]
int[] arr = [..128:1];             // new int[128] filled with 1
int[] arr = [0..64:1, 64..128:2];  // partial range-based fill
int[] arr = [128..:5];             // size inferred from highest index

This allows more expressive, readable, and compact array declarations and eliminates boilerplate when working with large or pattern-based arrays.

Motivation

C# has evolved toward more concise, expressive syntax (e.g., new(), collection expressions, ranges). However, array allocation remains verbose, especially when initializing large or structured arrays:

int[] arr = new int[128];
Array.Fill(arr, 1); // or loop manually

This proposal introduces a syntax that is:

• Easy to read and write

• Familiar to anyone using ranges or slicing

• Compatible with type inference on the left-hand side

• Extensible to future features (spans, multidimensional arrays)

Syntax Details

✅ Basic Allocation

int[] arr = [..128]; // Equivalent to: new int[128]

✅ Uniform Initialization

int[] arr = [..128:1]; // Equivalent to: Array.Fill(arr, 1)

✅ Range-Value Initialization

int[] arr = [0..64:2, 64..128:3];

Fills arr[0..63] with 2 and arr[64..127] with 3.

✅ Size Inference from Ranges

int[] arr = [128..:5]; // inferred size: 129

The compiler determines the array size from the highest index used.

✅ Mixed

int[] arr = [0:1, 1..4:2, 10..:3]; // inferred size: 11

Parsing & Disambiguation

[..N] without a target is not currently valid, so using it in a declaration is unambiguous.

In a declaration like int[] arr = [..128];, the compiler knows the expected type (int[]) and can treat [..128] as array allocation, not a Range.

If [..N:V] or start..end:V expressions are used, the compiler:

• Builds the array
• Applies fills left-to-right (last write wins)
• Infers the size from the maximum referenced index, if not explicitly specified

Grammar (Conceptual)

array-allocation-expression:
    '[' array-fill (',' array-fill)* ']'

array-fill:
    range ':' expression
    index ':' expression
    range-only           // [..N] form

range:
    '..' number
    number '..' number
    number '..'
index:
    number

Lowering Semantics

These expressions would lower to loops and Array.Fill calls, e.g.:

int[] arr = [0..64:2, 64..128:3];

Becomes:

var arr = new int[128];
Array.Fill(arr, 2, 0, 64);
Array.Fill(arr, 3, 64, 64);

Compatibility

✅ No conflicts with existing syntax:

• [..N] is currently legal but meaningless alone (only usable in slicing)
• No valid expression uses [..N] in assignment without an index target

✅ Backwards compatible

❌ Not allowed with var:

var arr = [..128]; // ❌ invalid, as type is required

Benefits

• ✅ Eliminates boilerplate for array allocation and initialization

• ✅ Improves readability and alignment with modern C# features

• ✅ Efficient: compiler can emit optimized loops or even static data

• ✅ Type-safe and bounds-checked

• ✅ Easy to extend to spans, multidimensional arrays, or other memory abstractions in the future

Future Directions

This syntax could potentially support:

• Span<T>:

Span<byte> buffer = stackalloc[..128:0xFF];

• T[,] multidimensional arrays (e.g., [0..3, 0..3:1])

Conclusion

This proposal provides a clean, expressive way to allocate and initialize arrays with syntax that is readable, compact, and aligned with C#'s design direction. It enhances the language's ability to concisely describe data layouts without sacrificing clarity or performance.

[CyrusNajmabadi]

For new feature proposals, however, please raise them for discussion, and only submit a proposal as an issue or pull request if invited to do so by a member of the Language Design Team (a "champion").

https://github.com/dotnet/csharplang/

[TizzyT566]

Oops, sorry about that and thank you.

[HaloFour]

[..N] is currently legal but meaningless alone (only usable in slicing)

[..N] is also a collection expression with a spread.

Not allowed with var

There are plans to change that by allowing collection expressions to have natural types.

[TizzyT566]

Hi @HaloFour,

You're absolutely right that collection expressions now support spreads using the .. syntax. However, as it stands today, a spread like [..128] is invalid because 128 is not an IEnumerable. So while the syntax form is technically legal within a collection expression, it produces a compile-time error in this case.

This proposal specifically targets that currently-invalid usage - [..128] where the operand is not enumerable - and assigns it new semantics when the expected type is an array, making it unambiguous in that context (I hope).

Regarding var, you're also correct that future support for natural type inference in collection expressions could make var arr = [1, 2, 3] valid. However, in the case of [..128], there would still be no element values from which to infer a type, so type inference would likely fail without an explicit type hint. That said, this proposal I hope is forward-compatible and could work with var where enough type information is available.

[HaloFour]

because 128 is not an IEnumerable

Which could change with extension implementation.

[TizzyT566]

I don’t think potential extension hijacking is a strong reason to block this proposal, since similar issues already exist in C# today - whether or not this feature is added.

If extension-based spreading is implemented in the future, it could introduce some ambiguity, but I believe such cases would be manageable through contextual analysis, compiler rules, or adjustments to this proposal’s syntax.

Overall, I consider this proposal technically safe and forward-compatible, with risks no greater than those already accepted by the language.

[huoyaoyuan]

It is a strong reason. This would cause syntax be changed by semantic (meaning of [..a] changed by type of a), which is disallowed. A different syntax must be used.

[timcassell]

Terse != readable. The examples are very ambiguous to my human eyes as to what they mean. [..128] looks more like [..Enumerable.Range(0, 128)] than new int[128].

[TizzyT566]

Hi @timcassell,

You raise a fair point - terse doesn't always mean more readable, but readability can be subjective. That said, I think [..128] strikes a good balance: its meaning becomes (I hope) intuitive when seen in context with an explicit array type, like int[] arr = [..128];.

Even if the underlying semantics are not immediately obvious to every reader, the intent - "give me an array of 128 elements" - is clear and matches what many developers already write with new int[128]. It behaves the same way as something you already know (new int[128]), and that intent is recognizable when reading the code - especially with an explicit type.

[HaloFour]

I think that this existing discussion is relevant. even though the syntax is different: #9515

[CyrusNajmabadi]

Closing as dupe of #9515. Let's keep the discussion and syntax ideas there.