Niko Matsakis

We've had a lot of evolutions of the lang-team process. After the long discussion in yesterday's triage meeting, I wanted to leave a comment to clarify how I see it...

Also, to be clear, we should absolutely reserve the keyword in Rust 2024. We know this is an important feature and, while it may not be available by Rust 2024,...

~~I've been thinking about this. From a **procedural** point of view, for reserving the `gen` keyword in RUst 2024, I think we should just open the PR to do that...

@withoutboats I remember you were blogging about that -- let me go read up. I agree it's a hard technical problem, but I'm not ready to give up yet. One...

@yoshuawuyts > If I'm understanding the new process correctly, it means there are no blockers in order to move forward with what's being proposed by this experimental RFC. Correct. >...

I'm frustrated by this RFC because the overall direction is *obviously* right to me, but the overloading of `unsafe` feels awfully subtle overall. I feel like we keep doubling down...

One specific concern I have: * What is the proportion of external functions that can correctly be safe? i.e., we have to weigh the risk of people accidentally writing `unsafe...

@rfcbot reviewed I don't love the `safe` keyword, but I concur with the [reasoning @pnkfelix laid out here](https://github.com/rust-lang/rfcs/pull/3484#issuecomment-1758275493) that got us there. I think we should consider a `trusted` keyword...

@rfcbot concern choice-of-keyword I guess, to @rust-lang/lang, I'd like to ask: Should we opt for `trusted` instead as the contextual keyword, for better future compat? Or do we think `safe...

@rfcbot resolve choice-of-keyword We discussed this in the @rust-lang/lang meeting and @pnkfelix convinced me that the contextual keyword `safe` is a reasonable choice here -- in particular, the point where...