[InlineArray] is not particularly array-like

[masonwheeler]

The new [InlineArray] feature looks really nice at first. Being able to create inline arrays without going into unsafe territory is something that's been notably missing from the C# language for a long time now. But when you try to use it, it doesn't really work like an array. Yes, arr[index] syntax works, but that seems to be the only thing that works.

One of the most common array operations, if not the most common, is iteration: either going over every element with a foreach loop, or going over every index from 0 to Length - 1 with a for loop. But an inline array provides neither a GetEnumerator nor a Length property. And while the former is understandable — inline arrays aren't "real" afterall; they're a trick implemented under the hood by compiler magic — the latter is less so.

Would it be possible to apply some of the same compiler magic to create a fake Length property, that the compiler substitutes with the constant Length value of the corresponding InlineArrayAttribute, so that at least for loops can be unblocked?

[CyrusNajmabadi]

InlineArray is intended to be the hidden backing storage, that is not used directly. Instead, you can just wrap it freely as a span, and then get all the niceties of that higher level abstraction.

[CyrusNajmabadi]

Would it be possible to apply some of the same compiler magic to create a fake Length property,

This should be possible with extensions in c#13

[CyrusNajmabadi]

The compiler does this, by allowing you to safely access through a Span or ReadOnlySpan. That's the published and expected pattern for working with inline arrays.

We don't have a desire for the compiler to reimplement the span surface area on these backing segments. The idea is to then use span to uniformly work with them like any other segment of memory (on the stack, heap, data segment whatever).

[masonwheeler]

That kind of makes sense, to say "Span is the primary supported use case here." But on another level, it doesn't.

• With an inline array, bounds checking of constant indices can be done at compile time. With a span, this is a runtime check.
• Inline arrays are quasi-functional as "arrays," supporting array[index] syntax. But trying to use them for any common array use cases, such as passing it to an array-typed parameter, running a for or foreach loop over it, or running a LINQ query on it, fails. Spans only fix half of that, because a span still won't fit in an array-typed parameter and spans don't implement IEnumerable<T>, even though it has a GetEnumerator method that provides something that works with foreach's duck typing.
• Unless you're participating in a discussion like this, or happen to have read the documentation page I linked above, you have no idea that a span is even a use case at all. And let's be honest: for a great number of developers, possibly even a majority, their primary source of information about the shape of an API is not the documentation. They look at what the IDE shows them, in Intellisense and in the debugger, and if they need more than that they'll ask StackOverflow or ChatGPT. Documentation is a distant third. You can argue that it shouldn't be that way — and I would agree, to a certain extent — but you can't say with a straight face that that isn't true. If the primary intended use case is spans, then compiler magic should create a fake AsSpan (and possibly AsReadOnlySpan) method, because right now, if I say myInlineArray. in Visual Studio, when Intellisense pops up, it gives me no indication whatsoever that a span is a valid use case.

[TahirAhmadov]

Compile time bounds checking can only be done if the inline array is indexed with a constant, so any scenario like for and a variable i wouldn't be any better.
Inline arrays can't be passed to methods expecting regular arrays because those are heap allocated. The language really doesn't want to inject hidden allocations/copying. What if the method modifies the array (remember, arrays are mutable), then the caller doesn't see those changes in the inline array? If you're working with inline arrays, then you want to pass around Span<T> because those can point at heap arrays and inline arrays, as Cyrus mentioned.
Regarding LINQ, it's a known limitation caused by the inability of Span<T>, which is a ref struct, to implement interfaces, and that is being worked on (I believe). If you search for "ref struct interfaces", you will find issues/discussions about that.
Also, I'm not sure if it applies here, but there may also be a forthcoming improvement in the future which allows no-allocation in-memory queries (as opposed to current system which creates all kinds of closures etc.) That has also been proposed and discussed already.
Regarding lack of pointers towards spans when looking at the public API of inline arrays, perhaps you can ask the XML docs of the attribute to be modified to mention spans? That could be a worthwhile improvement.

[masonwheeler]

Compile time bounds checking can only be done if the inline array is indexed with a constant

Yes, that's what I said: "bounds checking of constant indices can be done at compile time." When working with the sort of low-level data representations where you'd want an inline array, that happens more often than you might expect.

If you search for "ref struct interfaces", you will find issues/discussions about that.

Yeah, I just ran across that this morning, actually. Looks interesting, and I'll be happy if it makes it into .NET 9.

Also, I'm not sure if it applies here, but there may also be a forthcoming improvement in the future which allows no-allocation in-memory queries (as opposed to current system which creates all kinds of closures etc.) That has also been proposed and discussed already.

I'm familiar with that one too. I like the idea in theory, but all the proposals I've seen are very messy, and I'm not sure if it's possible to do this in a cleaner way. Personally, I'd prefer to see a rewriter that can turn LINQ queries into equivalent foreach loops, but I don't know if that's possible with source generators. (It definitely is with stronger AST-based metaprogramming, but unfortunately the C# team decided not to go that route.)

[CyrusNajmabadi]

Unless you're participating in a discussion like this, or happen to have read the documentation page I linked above, you have no idea that a span is even a use case at all.

All our documentation on the topic says this. So if you even found this topic, you'd be informed that the purpose is to create values that can be used as spans.

[colejohnson66]

I know it’s a broken record (heh), but source generators can help you here. Have one detect [InlineArray] and write span/length properties.

[TahirAhmadov]

I'm wondering if an SG can generate an IEnumerable<T> implementation here? Sounds like that would be something very helpful to the OP author.

[colejohnson66]

What’s the purpose of an inline array if you’re just going to box it as an IEnumerable? At that point, allocating an array seems easier.

[TahirAhmadov]

Yes I alluded to non-allocation LINQ in my other comment above. I suppose if he wants to optimize code when 90% of the time LINQ isn't needed, but he does have one code path which is hit infrequently which requires LINQ for some reason (readability, etc.), then an IEnumerable<T> implementation can come in handy.

[masonwheeler]

What’s the purpose of an inline array if you’re just going to box it as an IEnumerable? At that point, allocating an array seems easier.

Working with binary data formats. If you have something whose on-disc/on-wire representation is (int, int, byte[12], byte, int), there's a lot of value in being able to just blit that into a struct that has an inline byte[12] and can be used as such.

[TahirAhmadov]

You can definitely make the SG create some LINQ-like methods on the inline array type, it wouldn't be perfect, but it can get you almost there for most scenarios. I experimented with it and the problem is chaining multiple LINQ methods. Because of the "no allocation" rule, you can't use interfaces. But a few simple scenarios can be achieved, I believe.

[HaloFour]

Honestly the only answer here should be to just cast it to a Span<T> and then get the Length. It jumps through a few hoops but at least the runtime seems perfectly capable of folding everything and just returning the constant value.

Everything else feels unnecessarily complicated to me. Extensions are not a good solution because it's not possible to write a single extension that can cover all inline array types. Source generators can technically get the job done, but they feel seriously overkill too. Given that the compiler knows at all times how long the inline array type is, it feels a little silly that it's not more trivial to just have the compiler emit a Length const or the like on the buffer type, but barring that, nothing is really simpler than casting to Span<T>.