I like how this blog post was written.

There are only three things Zig/Jai could do in face of this problem

1. Don't do any memoization at all and just see if the result has been computed before (would be extremely slow and probably dumb)

2. Memoize arguments which can become ingrained with the returned struct (which is what they already do)

3. The only other possible thing would be:

If the function that generates the struct is

  fn generate_struct(p) type {
    struct {
      field_with_default = f(p)
    }
  }

the compiler would have to detect if f(x) is a one-to-one function or not. If it is then strategy 2 can be used safely, if it isn't then you'd have to use strategy 1.

the only issue with this third option is that from trying to read mathematics far beyond my pay-grade it seems like generally determining if any given f(x) is one-to-one is an undecidable problem for functions with unbounded domains and ranges. For functions that have bounded domains and ranges (say, functions that can only operate on integers within 0 and 4 billion) it's easily decidable... if you plug in every possible input and see what comes out.

This would take so much more time than even strategy 1 and I'm not even sure how useful it would really be. Maybe in a much much much more complex codebase that was doing a lot of weird things something like this might become a bug? Idek

So unfortunate as it is, I think strategy 2 is the best option.

Or we can go the OCaml route, admit that we want both applicative and generative functors, and add an explicit marker to the type-returning functions whether those generated types should always have unique identity, or not.

Or reduce scope: don't make it too darn flippin complicated to define structures.