# Design meeting: `#[diagnostic]` RFC

https://github.com/rust-lang/rfcs/pull/3368

## Notes

estebank:

### Versioning scheme

tmandry: Why not use editions?

Georg: Originally proposed by Josh. Originally we were going to make it so we could drop support at any time.

Georg: 3 years is a long time; I'd expect faster change than that.

estebank: That shoud be fine, we are going to go through the same nightly process. The main issue I see is that we want to be able to drop support.

tmandry: It's technically feasible to remove support for these for older editions

estebank: It would rely on the edition mechanism but change what it means, but only for diagnostics.

estebank: Generally speaking I'm not concerned about needing to support things for 3 years.

oli: Will it be possible to drop things?

estebank: As long as we have the escape hatch to remove things I think it will be okay. Not that we plan to do this all the time.

pnkfelix: I would think of this as a breaking change, the only way to do that is if we have rustfix to automate the change. Right?

estebank: Right

tmandry: You would want to add support to rustfix, then drop it 3 yrs later?

estebank: Yes

pnkfelix: Whaaat, we can just break this?

estebank: Original proposal was .... In ten years I don't want to have five ways to customize diagnostics.

estebank: We would never cause a compiler/parse error.

Georg: In the RFC it originally said the compiler must be able to parse, but it's up to the compiler to decide if it will use it or it's a no-op.

tmandry: My preference is still to use editions, but I see the point about changing what they mean.

oli: I would be fine with saying we won't break but have to choose a new attribute, and the old one won't do anything anymore.

estebank: That proposal conforms with the original version.

tmandry: I see 3 variants...

1. Version namespace (`diagnostic::v3::`)
- `#![diagnostics::version(v2)]`
- `#[diagnostics::on_unimplemented(v2, ...)]`
2. Edition
3. Ad-hoc renaming (`diagnostic::foo` instead of `diagnostic::bar`)

estebank: For 2 or 3 we could move from one to the other. If we were to commit to supporting everything for 3 years and switch to one or the other.

tmandry: Agreed... is it clear what will happen with macros?

oli: It should just work.

tmandry: Use case I'm imagining: You have a macro that expands to

#[diagnostic::foo]
struct Foo;

oli: Across an edition we could move to a version scheme.

tmandry: I propose we do the "simple thing". Meaning we assume we have ad-hoc renaming/support through the edition, and come back when we want to change something.

oli: Have to manage expectations about stability.

estebank: Agree

Georg: Example of how something might break: message field, note field, etc. One of these might not be used in the future.

oli: We could always stringly dump it into the output somewhere.

tmandry: I'm comfortable with saying we might turn these into a no-op, but

estebank: Need to be extremely clear that this is never going to cause a compilation regression. We aren't going to break people's code just because we want

oli: Including bumping MSRV. It shouldn't bump to adopt a new diagnostic attribute – other than originally adding the diganostic attribute itself.

tmandry: Hopefully with a warning for the _current_ crate if something is unrecognized?

estebank: For forward-compat, are we just going to accept anything and give a warning?

tmandry: My feeling is that it should be a warn-by-default lint, which should be turned off for all your deps.

oli: Our lint policy should be lenient enough to make this work.

tmandry: Do you want pre-approval for adding, removing, changing?

oli: For adding we'd like pre-approval, for removing or changing we are fine with looping in lang team.

estebank: I'd expect compiler to be looped in more for adding new attributes

oli: And adding new fields to existing attributes.

tmandry: Makes sense.

tmandry: Several members of the lang team wanted to have final signoff before things hit stable.

oli: I'm fine with doing it for the first few. After that it could get too high-frequency.

tmandry: How about if the RFC says we'll define a policy that can work around lang team later on, with lang team signoff (and not another RFC)?

room: (sounds reasonable)

tmandry: Not clear to me what the right sign-off/check-in mechanism with the lang team is, but I agree we probably don't want lang team signoff for every new field.

estebank: Expectation is that there will be a flurry of activity in the next 6 months, and then it calms down.

Georg: Maybe we require signoff for a new attribute, not new fields?

tmandry: I could see that being reasonable, with a ping for new fields that's non-blocking, or something like that.

tmandry: Or maybe we could try to discuss possible fields when discussing a new attribute.

esteban: I'd love to be able to add the diagnostic namespace so we can start parsing it now, so you don't bump MSRV further.

tmandry: Sounds like a great reason to prioritize this RFC.

oli: Should we immediately lint any use?

tmandry: Yes

estebank: Should do a crater run also

### Could/should we tie diagnostic::v to Rust version?

pnkfelix: I'm guessing that the intent is to allow the diagnostic version to increment at its own pace, though presumably one would observe an increment taken from *just* {0,1} in between each Rust verison.

pnkfelix: Would there be any value in instead encoding the Rust version itself in the `diagnostic::v`, to reduce the number of distinct version sequences Rust developers have to think/reason about?

###

yourname: Copy this template and add a note above.

###