That makes sense, though I'm not seeing much documentation on the array loops, only seeing the Functions - Loop Control bit. Are there any other examples of arrays being used recursively?

I guess what I want to do is

import std.array;

struct SecondaryStruct {
  // ...
  type::Hex<u32> data_offset;
}

struct MainStruct {
 // ... 
 u32 num_sections;
 std::Array<SecondaryStruct, num_sections> sections;
}

struct SectionData {
  // ...
}

MainStruct header @ $;

// then create an array? of SectionData structs for the offsets we have. i.e.:
// SectionData sectionA @ header.sections[0].data_offset;
// SectionData sectionB @ header.sections[1].data_offset;
// SectionData sectionN @ header.sections[N].data_offset;

There may be additional things I want to do with those sections in terms of using them in functions to extract data. So it might be worthwhile making that also an array. Hopefully that gives a bit more context of what my goal is here, let me know if not.

In a minimal example you remove all unnecessary details and focus on the problem at hand. One part you don't specify is how the data is stored at those addresses so I just used a generic name for a type (DataStruct) . The following pseudo code will show how one may approach these type of formats using the concepts described above.

import std.core;

struct SecondaryStruct {
  // ...
  u32 data_offset;
}


struct SectionData {
  DataStruct data @ parent.sections[std::core:array_index()].data_offset;
}

struct MainStruct {
 // ... 
 u32 num_sections;
 SecondaryStruct sections[num_sections];
 SectionData sectionData[num_sections];
}

MainStruct header @ 0;

// then create an array? of SectionData structs for the offsets we have. i.e.:
// SectionData sectionA @ header.sections[0].data_offset;
// SectionData sectionB @ header.sections[1].data_offset;
// SectionData sectionN @ header.sections[N].data_offset;

I meant that SectionData is the literal struct I want to place at each data_offset, I don't have another struct. My SectionData is just a random u32 for marking purposes within the file, nothing of significance.

I'd want it to be also outside of the header scope, so not a descendant of MainStruct.

Maybe closer to

struct SecondaryStruct {
  // ...
  type::Hex<u32> data_offset;
}

struct MainStruct {
 // ... 
 u32 num_sections;
 SecondaryStruct sections[num_sections];
}

struct SectionData {
  u32 testl
}

MainStruct header @ $;
// SectionData data_sections[header.num_sections] @ header.sections[ .. some way of creating SectionData at each offset ..].data_offset;

Okay thanks that made a lot more sense. I just wasn't completely sure on the syntax. I just wanted to avoid using a struct to call another struct at a location. I know inline exists but it in experimenting I didn't like how it represented the start address within the pattern view.

The thing is that it can't be avoided for this use case. I don't know what difficulties you are having using inline. There are several ways to apply it effectively and each is designed to have the best side effects that users have asked for. You can use it to suppress nodes, you can also use it to eliminate array indices. inline doesn't modify any address in the pattern data view. I haven't run into a situation that couldn't be handled with combinations of attributes. It sounds like you didn't experiment extensively. Here is an example of what I was able to do with the following code

import std.core;

struct SecondaryStruct {
  // ...
  u8 data_offset;
}[[inline]];

struct SectionData {
u8 t[3];
}[[sealed]];


struct DataStruct {
  SectionData sectionData @ parent.sections[std::core::array_index()].data_offset;
}[[inline]];

struct MainStruct {
 // ... 
 u8 num_sections;
 SecondaryStruct sections[num_sections];
 DataStruct data[num_sections][[inline]];
};

MainStruct header @ 0;

this is the pattern data view

there are no problems with addresses and you can't even see arrays or the structs you want to hide. show only what you want.

Ah, I see. I think the difference was I was adding the inline tags to the objects, not the structs themselves. That seemed to fix all of my issues with the addresses.

Attributes can be applied to the pattern or to the members. The effect they have on each mode varies with attribute, but it generally does what you would expect. If you are interested in learning, I really recommend looking at and running patterns in the library to see a wider range of what Pattern Language can do. Reading the docs only gives you a very basic look.