github.com
Rust project goals: Immobile types and guaranteed destructors
Rust project goals: Immobile types and guaranteed destructors
Substantive discussions about the Rust language itself as a project — language design, RFCs, the compiler, type system, memory model, governance, and Rust's future direction. Excludes crate releases and ecosystem projects.
Feed on Blueskygithub.com
Rust project goals: Immobile types and guaranteed destructors
Rust project goals: Immobile types and guaranteed destructors
github.com
Rust project goals: Immobile types and guaranteed destructors
Rust project goals: Immobile types and guaranteed destructors
corrode.dev
Understanding Dyn Compatibility | corrode Rust Consulting
In Rust, some traits can’t be used as trait objects with dyn Trait. When a trait can’t be used with dynamic dispatch, we say it’s “not dyn compatible.” 1 This has an impact on how you can use these tr...
github.com
rustdoc: Only build extern trait impls if needed by camelid · Pull Request #159623 · rust-lang/rust
View all comments or, finally remove the BadImplStripper! Building inlined impls is expensive, and most of them end up being unneeded and stripped later in this function. So we should filter them ...
nnethercote.github.io
How to speed up the Rust compiler in July 2026
My last post on the Rust compiler’s performance was in December 2025. Let’s see what has happened since then.
github.com
rustdoc: Only analyze head of self type when deciding impl inlining by camelid · Pull Request #159854 · rust-lang/rust
View all comments We only care about whether the self type is a generic or an item (inlined) in the current crate, so we don't actually need to compute the param_env, which is expensive when d...
github.com
Tracking issue for RFC 3681: Default field values · Issue #132162 · rust-lang/rust
View all comments This is a tracking issue for the RFC "3681" (rust-lang/rfcs#3681). The feature gate for the issue is #![feature(default_field_values)]. Allow struct definitions to provide default...
rossabaker.com
Rust Book, Chapter 6: Enums and Pattern Matching
Chapter Six I am still primarily a Scala 2 developer, so I’ll continue to lean into sealed traits in these examples. Scala 3 `enum` covers many of the same ideas, and in a syntax closer to Rust’s! ## Defining an enum # A Rust enum implements sum types, as Scala 2 does with sealed traits. The variants `V4` and `V6` are like the case classes and objects that extend the trait. CC-BY-SA-4.0 enum IpAddrKind { V4, V6, } CC-BY-SA-4.0 sealed trait IpAddrKind object IpAddrKind { case object V4 extends IpAddrKind case object V6 extends IpAddrKind } All the struct types we saw in the previous chapter are available here. The Scala `Write` is not a zero-cost newtype like Rust’s mostly to avoid a lengthy digression into Scala 2’s various encodings and tradeoffs. CC-BY-SA-4.0 enum Message { Quit, Move { x: i32, y: i32 }, Write(String), ChangeColor(i32, i32, i32), } CC-BY-SA-4.0 sealed trait Message { case object Quit extends Message case class Move(x: Int, y: Int) extends Message case class Write(value: String) extends Message case class ChangeColor(r: i32, g: i32, b: i32) extends Message } ### `Option` # Rust’s `Option` is familiar to Scala’s. CC-BY-SA-4.0 enum Option<T> { None, Some(T), } CC-BY-SA-4.0 sealed trait Option[+A] case class Some[+A](a: A) extends Option[A] case object None extends Nothing A couple headaches are gone in Rust: * Rust has no `null`, so there is no `Some(null)`. This doesn’t come up often in practice in Scala, but it’s a cost of Java interop. * No variance or quirks thereof! ## Pattern matching # Rust’s pattern matching is syntactically different from Scala’s, but conceptually almost identical. As a new Rustacean, this made it frustrating to write but intuitive to read. The important bits are the same: * Matches are exhaustive. This is good today when you forget one, and great tomorrow when you add another variant and the compiler tells you what you need to fix everywhere in your app. * Matches can bind values: `Some(x) =>` safely gets `x` out of the `Option` if and only if it’s `Some`. The only tricky bit here is that Rust’s ownership rules still apply. * Literal values can be matched. ## Rust variants are not types # Scala’s sealed trait model is based on on subtyping. `Some(42)` is both a `Some` and `Option`. `None` is both a `None.type` and `Option`. Rust enums are more like having just `apply` and `unapply`: we can construct and pattern match `Some` and `None`, but because there is no subtyping, the values have just one type: `Option`. ### Nested sum types # Scala’s model easily extends to multiple levels. A URI may have an authority, which is either a registered name or an IP address. The IP address may be either IPv4 or IPv6. CC-BY-SA-4.0 sealed trait Authority case class RegName(value: String) extends Authority sealed trait Ip extends Authority case class IpV4(…) extends Ip case class IpV6(…) extends Ip We can just as easily define functions that accept or return `Authority`, `Ip`, and `IpV4`, operating at the right level of abstraction for the task at hand. In practice, what Rust gives us is often enough: how often does a Scala signature explicitly refer to `Some` or `None.type`? In cases that it’s not enough, we can define structs for each concrete data type, and then each variant can wrap either a struct or another enum. CC-BY-SA-4.0 enum Authority { RegName(RegName), Ip(Ip), } enum Ip { IpV4(IpV4), IpV6(IpV6), }; struct RegName(String); struct IpV4(u32) struct IpV6(u64, u64); ## Control flow # Rust has two control flow syntaxes that are unfamiliar to Scala developers. ### `if...let` # Rust: CC-BY-SA-4.0 let config_max = Some(3u8); if let Some(max) = config_max { println!("The maximum is configured to be {max}"); } In Scala, we have to explicitly map the `None` to `()`. CC-BY-SA-4.0 val configMax: Option[Int] = Some(3) configMatch match { case Some(max) => println("The maximum is configured to be {max}") case None => () } As a functional Scala developer, I’d use `IO`. #+begin_aside I’d actually use `Console[F]`, but we’re here to learn Rust, not fight the old Scala wars. println(“The maximum is configured to be {max}”)#+end_aside CC-BY-SA-4.0 val configMax: Option[Int] = Some(3) configMatch match { case Some(max) => IO.println("The maximum is configured to be {max}") case None => IO.unit } Because `Option` can be traversed and `IO` is applicative, we can turn the `Option` into an `IO` by giving a function of what might be in the `Option` (`Int`) to `IO`: CC-BY-SA-4.0 configMatch.traverseVoid(max => IO.println(s"The maximum is configured to be $max")) Imperative Scala is more verbose than Rust in this case, but once we get back to working with pure values, Cats can be more concise!