https://300watts.me/tags/trait/Recent content in Trait on 300.WattsHugoenmorristai01@gmail.com (Morris)morristai01@gmail.com (Morris)This work is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License.Sun, 10 Mar 2024 10:04:55 +0800https://300watts.me/posts/async-in-traits-just-save-us/Sun, 10 Mar 2024 10:04:55 +0800morristai01@gmail.com (Morris)https://300watts.me/posts/async-in-traits-just-save-us/<h2 id="the-challenge-of-implementing-the-future-trait-for-custom-types" class="headerLink"> <a href="#the-challenge-of-implementing-the-future-trait-for-custom-types" class="header-mark"></a>The Challenge of Implementing the Future Trait for Custom Types</h2><p>Developers who venture into crafting their own <code>async</code>/<code>await</code> implementations in Rust may encounter the intricate task of implementing the <code>Future</code> trait for their custom types. Rust&rsquo;s approach to <code>async</code>/<code>await</code> is nuanced, offering a stark contrast to languages like Go, which employ preemptive scheduling. Instead, Rust embraces lazy evaluation and cooperative scheduling, allowing developers to meticulously control the yield points to the executor. This level of control, however, introduces complexity in implementing the <code>Future</code> trait for custom types. The intricacies arise because <code>.await</code> can&rsquo;t be invoked within a <strong>non-async</strong> function, necessitating the development of a state machine (or similar) for these custom types. This endeavor can be laborious and fraught with potential errors, difficult to maintain, and may prompt developers to opt for <code>BoxFuture&lt;T&gt;</code>, a choice that could compromise performance.</p>