To impl or not to impl: The State of Existential Types in Rust
summary
Traces the concrete differences between argument-position impl Trait (a universal/generic-like, nameable-at-call-time type) and return-position impl Trait (an opaque existential the compiler picks), explains why return-position is zero-cost compared to dyn Trait, and lists practical workarounds: boxing, the nightly type_alias_impl_trait/return-type-notation and the define opaque rule. Covers stabilization status and blocker: the new trait solver is required before several of these ergonomics become stable, and shows which current APIs break or need alternate signatures.
AI-written summary · about
chapters (13)
- 0:00Introduction
- 0:49Existential types history
- 3:40Return position input traits
- 6:48Naming problems
- 9:58Dynamic vs existential traits
- 12:45Dynamic traits limitations
- 15:32Stable support
- 16:56Impl trait in traits
- 19:46Input traits under the hood
- 21:51Solving naming problem
- 23:55Type alias impl trait
- 25:43Opaque types benefits
- 26:24Future of existential types
related talks
56m“Type Traits - what are they and why should I use them?"
38mExistential Types — Make OOP Great Again!
30mRust-Inspired Typescript
24mExistentialize your Generics
01h 01mConcepts vs Typeclasses vs Traits vs Protocols
36mRust's trait system is a proof engine, let's make it prove us an ABI!
01h 01mThe promise of static reflection in C++26: Type Traits without compiler intrinsics
29mExtending Rust’s notions of sizedness