# Private lifetime inference

**URL:** <https://internals.rust-lang.org/t/private-lifetime-inference/24088>\
**Category:** language design\
**Created:** [March 16, 2026, 8:45pm UTC](https://internals.rust-lang.org/t/private-lifetime-inference/24088 "2026-03-16T20:45:46Z")\
**Posts on this page:** 1\
**Showing post:** 13

<div class="post-metadata">

**Author:** ![scottmcm](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/scottmcm/32/2355_2.png) [@scottmcm](https://internals.rust-lang.org/u/scottmcm)\
**Post date:** [March 17, 2026, 6:00pm UTC](https://internals.rust-lang.org/t/private-lifetime-inference/24088/13 "2026-03-17T18:00:21Z")

</div>

TBH, getting lifetime bounds right is rarely the noisy part. I think it'd be entirely fine to solve that part like we solve `-> _`: with a structured suggestion inferred from the body.

Then I agree with the mention of a `macro fn`: then it could potentially even just be

```rust
macro fn find_best(primary, fallback) {
    if primary.is_valid() { &primary.summary } else { &fallback.summary }
}

```

where not only do I not need to put in the _lifetimes_ but I can even leave off the _types_ and have it just happen in the context of the caller instead.

Which would, among other things, be really really useful for math where writing out all the `num_traits` bounds is particularly annoying for a small helper.

---

_[View the full topic](https://internals.rust-lang.org/t/private-lifetime-inference/24088)._