Michael (compiler-errors) Goulet
@errs.io
lexington was horrendous earlier today, northbound 4 trains already 100% packed pulling into fulton and 5 trains were just skipping the station altogether
November 2, 2025 at 8:57 PM
lexington was horrendous earlier today, northbound 4 trains already 100% packed pulling into fulton and 5 trains were just skipping the station altogether
don’t forget 8av and central park west
October 28, 2025 at 7:48 PM
don’t forget 8av and central park west
how hard is it to paste an image into an image 😭
September 26, 2025 at 3:58 PM
how hard is it to paste an image into an image 😭
i dislike that one in particular. i'd be fine if it were a cheeky custom error message when the unresolved break target is `rust`, but it's implemented as a custom ICE in the compiler which is kinda annoying
September 23, 2025 at 7:16 PM
i dislike that one in particular. i'd be fine if it were a cheeky custom error message when the unresolved break target is `rust`, but it's implemented as a custom ICE in the compiler which is kinda annoying
not afaict, they’re ocaml as far as i can tell :)
September 9, 2025 at 10:40 PM
not afaict, they’re ocaml as far as i can tell :)
oh right, this all does remind me of implicits in scala. thanks for the terminology :)
September 9, 2025 at 7:21 PM
oh right, this all does remind me of implicits in scala. thanks for the terminology :)
I will note that the Rust compiler does distinguish "instance resolution" from plain ol' "solving goals". In typeck, we only care that a where clause holds, but it doesn't necessarily know what impl a solution comes from until codegen b/c of things like opaques, where clauses that shadow impls, etc.
September 9, 2025 at 5:47 PM
I will note that the Rust compiler does distinguish "instance resolution" from plain ol' "solving goals". In typeck, we only care that a where clause holds, but it doesn't necessarily know what impl a solution comes from until codegen b/c of things like opaques, where clauses that shadow impls, etc.
but it is a very good point that there is some flexibility lost, though I'm not sure if there isn't a way for traits to themselves implement some kind of rank-2 "kind" and make signatures generic over *those*, for example. it wouldn't be generalizable like functors are, tho.
September 9, 2025 at 5:36 PM
but it is a very good point that there is some flexibility lost, though I'm not sure if there isn't a way for traits to themselves implement some kind of rank-2 "kind" and make signatures generic over *those*, for example. it wouldn't be generalizable like functors are, tho.
Right, but I find that often I want my API to be meant for a single "kind" of trait. When I write `sum_values<T: Add>`, I don't want callers to provide an implementation of `Mul`, even tho it provides some binary `t -> t -> output`. So in a way it also kinda makes the API more self descriptive 🤔.
September 9, 2025 at 5:35 PM
Right, but I find that often I want my API to be meant for a single "kind" of trait. When I write `sum_values<T: Add>`, I don't want callers to provide an implementation of `Mul`, even tho it provides some binary `t -> t -> output`. So in a way it also kinda makes the API more self descriptive 🤔.
Another rust could be smarter about this or have chosen a different solver strategy, but lots of reasonable code relies on this incompleteness (we've encountered a lot of cases when working on the new solver lol).
September 9, 2025 at 5:32 PM
Another rust could be smarter about this or have chosen a different solver strategy, but lots of reasonable code relies on this incompleteness (we've encountered a lot of cases when working on the new solver lol).
The compiler today either just bails out with ambiguity if we don't know what to return from `.borrow()` (like we sometimes do) or be incomplete, and I guess we settled on reasonable heuristic of preferring where clauses + associated bounds which is (possibly surprisingly) often what the user wants.
September 9, 2025 at 5:32 PM
The compiler today either just bails out with ambiguity if we don't know what to return from `.borrow()` (like we sometimes do) or be incomplete, and I guess we settled on reasonable heuristic of preferring where clauses + associated bounds which is (possibly surprisingly) often what the user wants.
Yeah. The issue stems from the fact that there are essentially two things we're proving here that both involve inference: `O: Borrow<?0>` and `?0: PartialEq<?1>` here, and we don't really do solving at the "intersection" of two different goals even if both taken together would find a valid solution.
September 9, 2025 at 5:32 PM
Yeah. The issue stems from the fact that there are essentially two things we're proving here that both involve inference: `O: Borrow<?0>` and `?0: PartialEq<?1>` here, and we don't really do solving at the "intersection" of two different goals even if both taken together would find a valid solution.
the important part of (2.) is that modules (i.e. impls) themselves don't need names, since theyre uniquely identified by the `module type` being impl'd + the params, and we don't ever *need* to name them directly as a consequence of them being retrievable by this name
September 9, 2025 at 5:27 PM
the important part of (2.) is that modules (i.e. impls) themselves don't need names, since theyre uniquely identified by the `module type` being impl'd + the params, and we don't ever *need* to name them directly as a consequence of them being retrievable by this name
by 1. treating `modules type`s nominally rather than structurally, 2. and uniquely identifying each module with a set of input parameter types (i.e. no impl overlap), we can look up a module's components by name without referencing it directly, via the `module type` + generics
September 9, 2025 at 5:27 PM
by 1. treating `modules type`s nominally rather than structurally, 2. and uniquely identifying each module with a set of input parameter types (i.e. no impl overlap), we can look up a module's components by name without referencing it directly, via the `module type` + generics
Second example, yeah we prefer associated type bounds over impls so `owned.borrow()` is `&B`, which requires `B: PartialEq`.
September 9, 2025 at 5:02 PM
Second example, yeah we prefer associated type bounds over impls so `owned.borrow()` is `&B`, which requires `B: PartialEq`.
third example shouldn't be a mystery. `owned.borrow()` requires `O: Borrow<_>`. We prefer where clauses over the built-in reflexive `Borrow` impl, so we end up with type `&B`. That means we end up selecting the `B: PartialEq` impl in the where clause (elaborated from `B: Eq`) for the `==`.
September 9, 2025 at 5:02 PM
third example shouldn't be a mystery. `owned.borrow()` requires `O: Borrow<_>`. We prefer where clauses over the built-in reflexive `Borrow` impl, so we end up with type `&B`. That means we end up selecting the `B: PartialEq` impl in the where clause (elaborated from `B: Eq`) for the `==`.
we dont have the implication that the type U in `T: Tr<Assoc = U>` implies all of the bounds of Assoc onto U, unfortunately. Doing so leads to a complexity blowup that the old solver can’t handle and the new solver would probably also choke on.
September 6, 2025 at 4:06 PM
we dont have the implication that the type U in `T: Tr<Assoc = U>` implies all of the bounds of Assoc onto U, unfortunately. Doing so leads to a complexity blowup that the old solver can’t handle and the new solver would probably also choke on.
thanks! it’s a shame i didn’t get to work on rust for longer, but i hope i made my mark and i’m glad i’m settled job-wise. hope i get to work on rust or something equivalently impactful in the future, we shall see.
September 5, 2025 at 4:06 PM
thanks! it’s a shame i didn’t get to work on rust for longer, but i hope i made my mark and i’m glad i’m settled job-wise. hope i get to work on rust or something equivalently impactful in the future, we shall see.
I urge companies to take funding contributors seriously, in ways that aren’t tied to projects and goals. Being a generalist in the compiler meant that often I wasn’t working towards a roadmap, but my contributions *always* paid off in the long term extensibility of the language.
September 5, 2025 at 1:14 PM
I urge companies to take funding contributors seriously, in ways that aren’t tied to projects and goals. Being a generalist in the compiler meant that often I wasn’t working towards a roadmap, but my contributions *always* paid off in the long term extensibility of the language.
That does mean I’ll be scaling back my Rust contributions over the next few months before I start my new job. Sorry to the folks who were looking forward to stuff I had in the pipeline. I really would’ve liked to deliver async fn in dyn traits or `-Zhigher-ranked-assumptions`.
September 5, 2025 at 1:14 PM
That does mean I’ll be scaling back my Rust contributions over the next few months before I start my new job. Sorry to the folks who were looking forward to stuff I had in the pipeline. I really would’ve liked to deliver async fn in dyn traits or `-Zhigher-ranked-assumptions`.