Storing an Arena<AstNode<'_>> in a struct

[nic-hartley]

Hello! I'm trying to make something to the effect of:

struct SiteGenerator {
  arena: Arena<AstNode<'??>>,
  // ...
}

Cannot for the life of me figure out what the '?? should be, or lifetimes in return types, etc. (I tried adding a lifetime parameter, but predictably that didn't work; after all, the lifetime here isn't a parameter, it's the lifetime of the struct.) One option would be creating the arena externally and storing a &'a Arena<AstNode<'a>>, but that's... annoying? And I feel like there's a better way.

[rlidwka]

This should be a lifetime parameter of your struct (that's usual rust stuff):

struct SiteGenerator<'ast> {
  arena: Arena<AstNode<'ast>>,
  // ...
}

[nic-hartley]

I tried adding a lifetime parameter, but predictably that didn't work; after all, the lifetime here isn't a parameter, it's the lifetime of the struct.

Right, let me expand on that then. With 'ast as a lifetime parameter, how do you write a method like this?

fn parse_md(&self, contents: &str) -> &'?? AstNode<'ast> {
  parse_document(&self.arena, contents, &OPTIONS)
}

This is obviously very simplified from what I'm actually trying to write but the thing is, I'm trying to write something that returns an AstNode, and with a lifetime parameter that doesn't work. Because

the lifetime here isn't a parameter, it's the lifetime of the struct.

[rlidwka]

Can you show the actual code you're trying to write instead of individual code fragments?

As it is now, this would probably compile:

fn parse_md(&'ast self, contents: &str) -> &'ast AstNode<'ast> {}

[nic-hartley]

Unfortunately I can't easily show the actual code. It's not public (yet) and it's kinda weirdly interconnected.

That said, using &'ast self instead of &self everywhere does seem to work -- kinda surprised me, I thought lifetimes would conflict, but in retrospect it makes sense. A bit frustrating if this is the only way to store an Arena in a struct, though.

[nic-hartley]

Never mind, this does break how I thought it would -- just not in the toy example I started with. That said, I'm done messing around with this; I'll just pass in the Arena from outside and track it separately. In other use-cases it'd be a nightmare but here SiteGenerators are ephemeral and I can just do let a = Arena::new(); let sg = SiteGenerator::new(&a); and not have to worry about e.g. returning the SiteGenerator.

[kivikakk]

You certainly can store an Arena however you like, but I'm guessing the reason your non-example is breaking is because you're trying to store some state in the SiteGenerator which itself refers to something in the Arena. That then becomes a self-referential struct, which isn't generally possible in Rust (without e.g. pinning the struct); a move of the SiteGenerator would likewise move the Arena within it, which in turn would invalidate the member holding a reference to something in the Arena.

You could store the Arena in some higher-level struct, which SiteGenerators then refer to, but if the Arena's the only thing, might as well just do what you've decided on.

I'd suggest extracting your problematic case into something self-contained if you'd like help looking into it further, as diagnosing an unknown problem in an unknown construct is Hard.