fat struct style guide?

[monkyyy]

On Tuesday, 24 February 2026 at 16:45:30 UTC, H. S. Teoh wrote:
> On Tue, Feb 24, 2026 at 04:21:01PM +0000, monkyyy via 
> Digitalmars-d-learn wrote:
>> On Tuesday, 24 February 2026 at 16:19:05 UTC, H. S. Teoh wrote:
>> > On Tue, Feb 24, 2026 at 03:56:20PM +0000, monkyyy via 
>> > Digitalmars-d-learn wrote:
>> > > On Tuesday, 24 February 2026 at 15:30:39 UTC, H. S. Teoh 
>> > > wrote:
> [...]
>> > > > > What's a "fat struct"?
>> > [...]
>> > > Something like a "entity" that has a first member is a id 
>> > > allowing for intrusive sumtypes from void* pointers or a 
>> > > giant union and just allot of data.
>> > [...]
>> > 
>> > So is that like ECS or something along those lines?
> [...]
>> Related ideas, but ecs will definitely have components which 
>> is a whole thing of complexity and makes for scheduling and 
>> you start talking about custom compilers.
>> 
>> All good ecs will probably be fat structs, but components are 
>> not necessarily members of good entities.
>
> Hmm.  So basically the idea is to stuff everything into a 
> single struct so that you keep everything in cache instead of 
> having to dereference pointers?
>
> Sounds like something you could use compile-time introspection 
> for.  Say you have some kind of compile-time spec of what 
> sub-structs go into some entity, then have compile-time code 
> auto-generate the fat struct that contains everything in these 
> sub-structs.  Could do it in a way that makes it easy to change 
> at the code level without editing tons of struct definitions 
> (by using CTFE to generate said definitions and then mix them 
> in).
>
>
> T

Your thinking with oo and not type theory and anti-safetyism; it 
would be a style guide and acceptable callsite usage patterns; 
not a meta-program.

C-sytle code needs a compiler that handles offsets of structs and 
void* an oo-compiler needs an enforced type theory and 
indirection about every turn.

When you say "substructs" your imagining enforced type theory, 
when you say "autogenerate the fat struct" your ideas would then 
nesserisate type-indirection at the function level that would be 
very very complex to metaprogram or some new compiler feature 
like ecs.

Its c-like code and enabling "unsafe" void* hacks.

Gist code from last night(I already see one improvement and 
expect more):

```d
#!opend test app
import std;
import core.stdc.stdlib;
import core.sys.posix.dlfcn;

enum animalid{cow=7,chicken,horse};

struct animal{
     animalid id;
     string say;
     int age;
}

void apply(string s,T...)(ref animal a,T args){
     static void afunction(ref animal,T);
     alias F=typeof(afunction);
     Switch: switch(a.id){
         static foreach(C;EnumMembers!animalid){
             case C: (cast(F*)dlsym(null,s~C.stringof))(a,args);
             break Switch;
         }
         default: break;
     }
}

animal newanimal(string s){
     if(s=="cow"){
         return animal(animalid.cow,"moo");
     }
     if(s=="chicken"){
         return animal(animalid.chicken,"cluck");
     }
     return animal(animalid.horse,"niah");
}

void speak(animal a){
     writeln("this ",a.id," says ",a.say);
}

extern(C) void docow(ref animal a){
     "eat grass".writeln;
     a.age++;
}
extern(C) void dochicken(ref animal a){
     "attack zelda".writeln;
     a.age++;
}
extern(C) void dohorse(ref animal a){
     "run".writeln;
     a.age++;
}
void makechicken(ref animal a){
     a.id=animalid.chicken;
}

void old(ref animal a){
     a.age+=10;
}
int[animalid] maxage;
bool isdead(animal a){
     return a.age>maxage[a.id];
}

unittest{
     animal[] foo;
     foo~=newanimal("cow");
     foo~=newanimal("chicken");
     foo~=newanimal("idk");
     foo.writeln;
     foo.each!speak;
     foo.each!(apply!"do");
     //---
     foo.each!old;
     maxage[animalid.chicken]=5;
     maxage[animalid.cow]=15;
     maxage[animalid.horse]=10;
     foo.map!isdead.writeln;
     maxage[animalid.chicken]=500;
     foo.map!isdead.writeln;
     //---
     foo.each!makechicken;
     foo.each!speak;
}
```