Need help in designing a pretty complicated lifetime struct (async, generic etc.)

I'm working on a higher-level crate called fluent-fallback that is meant to provide a user-facing abstraction over low-level APIs that Fluent (localization system) works with.

The JS equivalent of that code is here: https://github.com/projectfluent/fluent.js/blob/master/fluent-dom/src/localization.js#L12

For Rust, I have the sync case working: https://github.com/projectfluent/fluent-rs/blob/master/fluent-fallback/src/lib.rs

And now I'm designing the async version. The async version is mean to provide analogous API except that it's async and the input method is returning Iterator over futures - this allows the FluentBundle to be generated asynchronously using async I/O.

I struggle to design the lifetimes to properly handle the async case. Here's a minimized testcase I came up with: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=0428a7823e2000a6a11461462a940aa1

Can someone help me squeeze the right lifetime bounds for this API?

Thank you!

Well, it's possible to get it to compile (Playground), but I'm not so sure it's going to do what you want.

It's also of pretty daunting complexity if you are going to need to maintain and debug it. I would strive finding an alternative and simpler design if at all possible. I would only ever consider keeping something like this as utter last resort, if I really can't find any better solution. For example, if you want to work with reference types because you are afraid that copying a few strings around would hurt performance to much, I would urge you to take the problem from the other end. Eg. get a working version as simple as possible, disregarding all performance considerations and then measure it. Start optimizing from there if and only if it's necessary.

In any case, you won't be allowed to call on_change while format_values is being awaited.

Probably easiest to throw it in a diff to see what I changed.

1 Like

Ah, thank you! So it was just about binding the lifetime in the closure!

Yeah, I agree its not optimal. I'll try to simplify it, but also expect that as Rust advances, we'll get more robust generators and async iterators and it'll all be easier to write :slight_smile:

Now that I think of it, for generators there are helper crates like next-gen.

There's a ton more on crates.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.