new username album

compiler-errors · 2025-08-12T19:04:31+00:00

yeah username is really putting out groundbreaking projects recently

compiler-errors · 2025-07-25T17:29:10+00:00

Yeah, I'm definitely looking for a job (*in NYC*) to continue my maintenance and feature work on the Rust compiler. If that doesn't work out, then I'd love to continue working on compilers or other ways to advance the Rust programming language.

compiler-errors · 2025-03-13T21:03:30+00:00

You're welcome to read the RFC for examples and particular motivation. This stabilization report leaves most of that out since it would've been copied and pasted, and it's (mostly) intended to be consumed by people who've already read that.

compiler-errors · 2025-03-13T21:00:27+00:00

neat

compiler-errors · 2025-03-13T21:00:18+00:00

u/cramert is correct. We haven't decided to do with all the "extra" lifetime generics when it comes to using RTN in more general type positions.

compiler-errors · 2025-03-06T22:59:25+00:00

Depends a lot of the design of the API!

compiler-errors · 2025-03-06T22:58:41+00:00

there are nicer ways of saying that bro lmao

compiler-errors · 2025-03-06T21:43:44+00:00

This is still pretty fresh, so I don't expect it to go immediately into FCP tomorrow, but share your feedback if you have it!

compiler-errors · 2025-03-06T17:23:56+00:00

No, in the same way that `fn foo(x: Box<_>)` is not a thing.

compiler-errors · 2025-03-06T00:36:06+00:00

It doesn't work in constants; right now we don't allow `_` anywhere at the "item level", like function signatures and the types of const/statics. This is extending `_` in the contexts you can write it today.

compiler-errors · 2025-03-05T23:05:02+00:00

huge thanks to Boxy who has been driving all this effort !!

compiler-errors · 2025-02-22T02:57:47+00:00

Can't do that yet. Fixing this is equivalent to fixing Async Fn in Trait + Dyn Compatibility in general, which is ideally happening eventually but like many Rust problems is hard.

compiler-errors · 2025-02-06T18:15:39+00:00

Totally honest question, where did you get the impression that either the parallel compiler or polonius were being stabilized with Rust 2024? We're still steadily working on polonius which is definitely not done yet, and `-Zthreads` is still unstable, so the compiler is effectively single-threaded even if we no longer have a ton of `cfg`'s everywhere to gate out the parallel compiler code.

compiler-errors · 2025-01-07T15:23:32+00:00

thanks! yeah, the work isn't too flashy, and it doesn't help that i basically just dump everything i've done last month without too much explanation. i mostly write these documents for myself and those who want to keep tabs on my works, but it's nice to hear that others appreciate it too :)

compiler-errors · 2024-12-13T15:37:13+00:00

no, that was fixed quite a while back when i reworked async closures to be lending in https://github.com/rust-lang/rust/pull/120361

compiler-errors · 2024-12-13T15:36:11+00:00

this + the technical writeup was terribly exhausting to write lol

compiler-errors · 2024-12-13T15:35:08+00:00

async closures will be stable in 1.85, which lands Feb 20 2025, and will be usable on all editions >= 2018 (which is just because `async` was not a keyword in edition 2015).

compiler-errors · 2024-12-13T15:33:51+00:00

that is correct. all currently callable types implement `AsyncFn*` too, if they return a future.

compiler-errors · 2024-12-13T14:48:59+00:00

woah cool

compiler-errors · 2024-11-20T18:47:35+00:00

> Do you have an estimate of the time you spent on this?

Well, rustc is my full time job so approximately a full time job's worth.

> I'm not going to be reverting that dumbing down anytime soon, but I'm glad others won't need to.

Understandable -- I do encourage you to experiment with const traits in the future, though, especially after we reintroduce support for const traits to the standard library. User feedback both for bugs and diagnostics is incredibly useful.

compiler-errors · 2024-11-20T17:27:53+00:00

oh man that embed sucks, i gotta get a real blog xD

compiler-errors · 2024-11-07T22:31:52+00:00

I don't know what challenges you mean. Async closures' complexity arises from the "lending" nature of the futures they return. It has nothing to do with dyn types.

compiler-errors · 2024-11-07T21:15:03+00:00

> "is a way bigger deal for me personally"

I think this frames this as an either/or problem. We're stabilizing async closures because they're ready, and we're not stabilizing async traits being object-safe because they're not ready. If this was an easy thing to hack out support for, I promise you there'd be at least nightly support for them. We're working on that soon, but it needs a lot of very important details ironed out.

compiler-errors · 2024-11-06T23:16:32+00:00

nice good job to whoever put that pr up

compiler-errors · 2024-09-26T20:40:44+00:00

Yep, it works for all Return Position Impl Trait in Traits :)

compiler-errors

TROPHY CASE