---
title: "Design meeting 2023-11-15: 2024 Edition Review"
date: 2023-11-15
tags: T-lang, design-meeting, minutes
discussion: https://rust-lang.zulipchat.com/#narrow/stream/410673-t-lang.2Fmeetings/topic/Design.20meeting.202023-11-15
url: https://hackmd.io/KF7t6VlCTHKCO0y7EY7Rrw
---

# 2024 Edition Review

We need to discuss the list of candidate changes for the 2024 edition, and categorize them according to whether we expect to ship them and whether they have an owner.

## Background reading

I made a Github project

* [Lang Edition 2024 project](https://github.com/orgs/rust-lang/projects/43/views/2)

listing all the issues from this doc, as well as the labels that were originally used as sources for it:

* [2023-06-28: Rust 2024 Survey](https://hackmd.io/itGzgM1fQl-oh4d1iP8sFg)

## Meeting outline

https://github.com/orgs/rust-lang/projects/43/views/2

Time limit per issue: 5 minutes (can come back at the end of the meeting)

* Workflow meetings going forward: Edition-nominated section at the beginning
* Go through accepted
* Go through nominated rejected
* Go through "ask"
* Do we want to "tell a story"?
* Priorities and risks
* Mainly, most of these need a champion on the impl side

# Minutes

People: TC, tmandry, JT, scottmcm, waffle, Urgau, nikomatsakis

Minutes: TC

## Temporary lifetimes

nikomatsakis: I've been working with Mara + Xiang Ding Fei on a proposal for revised temporary lifetime rules. This will be a Rust 2024 breaking change in that the behavior of some constructs, like `match foo().lock() {...}` would change.

NM: Some set of temporary lifetimes would become shorter, especially around match statements. That's the edition part. It definitely needs an RFC.

## Non-terminals, e.g. expr, have diverged between parser and macro matcher - #86730

https://github.com/rust-lang/rust/issues/86730

JT: ...we have precedence here.

NM: It'd be good to have a name that's useful rather than using the year.

JT: Agreed, not making a propsal on the name.

NM: It'd be good to write up something in the lang-team repo about a policy or a habit here, that we try to update this on editions.

JT: Does it need an RFC?

JT: Proposal: We should write a general policy that we update the macro matchers in the new edition, and we use this particular naming system. After we FCP that policy, then someone needs to write a policy for expr.

tmandry: +1, but it needs someone to write the RFC.

TC: I'll have a look. Lokathor may also have interest.

*Consensus*: We'll write a policy RFC here, then consider this specific case in that context.

## Reserve `gen` keyword in 2024 edition for Iterator generators - #3513

TC: It's on my plate to update this RFC, but the key edition question is reserving the keyword.

JT: ...

NM: Maybe we should say, yes we want it, and then deal with the bikeshed in triage later.

all: +1.

*Consensus*: Let's move to accept.

## `Box<[T]>` should have an IntoIter implementation. - #59878

*Consensus*: No objection. We should do this.

## Clean up items accidentally stabilized through unstable paths - #113387

tmandry: The main question is whether this is a lang concern, particularly some of the items.

JT: Probably not.

*Consensus*: We'll mark this as not-lang.

## make pub type foo = bar and pub use bar as foo interchangable in next edition - #73191

*Consensus*: We might accept if an RFC happened. We've left a note.

## Extern types v2 - #3396

tmandry: There's not a consensus proposal for any edition change, and we can accept it without an edition change.

JT: +1.

*Consensus*: This doesn't need an edition.

## Tracking Issue for `#[deprecated_safe]` attribute - #94978

JT: Libs would really like this from lang. But the other question is, why does this need an edition?

JT: Whether we do this is a lang concern, and it lets others tie things to editions, but it's not tied to an edition on the lang side.

all: +1.

*Consensus*: This doesn't need an edition.

## Shorten drop scope of temporaries in conditions - #111725

NM: Is is probbaly overlapping with the other work. This might unblock some other feature... but that may be something else.

tmandry: We can probably roll this into the other one.

NM: That's fine.

*Consensus*: We probably don't need to consider this separately.

## Tracking issue for deprecation lint proc_macro_derive_resolution_fallback - #83583

tmandry: We've had a design meeting proposal on the books for most of this year but haven't had the design meeting.

pnkfelix explains why this is hard here:

https://github.com/rust-lang/rust/issues/83583#issuecomment-1397867288

*Consensus*: This one needs a proposal.

## Meta: How do we get through the rest?

TC: We should think about how much time we have remaining before all this work needs to be finished and whether we can get through it with the number of weeks and number of meetings remaining.

*Consensus*: To get through the rest, let's nominate this issue for discussion at the next available design meeting. We'll also go through some of these issues in each triage meeting. And perhaps we can complete the scheduling of the design meetings for next month during triage this month to free up one design meeting slot.

(The meeting ended here.)