we reserve the right to reduce our amount of UB

[RalfJung]

It was pointed out to me that the docs currently say that the things on the UB list are definitely UB. That's not true, we do reserve the right to have less UB in the future. (Exactly that is happening e.g. in #1387.)

[pnkfelix]

@rustbot label: +I-lang-nominated

I want to discuss this at the @rust-lang/lang design team meeting. In particular, on the associated zulip thread where I asked why someone would want the prior interpretation of this text, a couple interesting cases were described:

• I hypothesized, as a strawman, that compiler optimization authors want it so they don't have to update their code when the language spec changes
• @chorman0773 pointed out that some API's might be written in a way where they just say "precondition: *x is a legal operation", and then treat the implications of that according to this list at the time when they are writing the API as something they can assume for all time.
• @RalfJung pointed out their own motivating case, which is verification tools that want to similarly make assumptions in their reasoning based on the UB list.

[joshtriplett]

Suggested change

	behavior in that list defined in the future.
	behavior in that list defined in the future, or conversely, to guarantee that it will always be undefined.

[RalfJung]

I am confused, this now says "we reserve the right to [...] guarantee that it will always be undefined"?

[tmandry]

I think Josh is trying to capture the point that Niko raised below: We may want to promise that certain operations will always be UB, so that unsafe code can rely on that. edit: I don't personally think it's necessary to say this, but perhaps it would be good to say, ideally in another sentence to reduce confusion.

[RalfJung]

I don't understand the point of saying "in the future we may want to promise that something will always be UB". On its own, how is that statement useful for anyone? I would understand the point of marking particular items in the UB list as "this will definitely always be UB", but we don't currently have any such items, or do we?

[joshtriplett]

@RalfJung The wording could absolutely change. The wording currently in the PR says that we could define it in the future. The point Niko made, which I wanted to capture, was that we could also commit to not defining something (or for that matter commit to not defining it in particular ways), which is something that some crates may need us to do.

I agree that that's already implicit, but at the same time, someone reading this might want to rely on a guarantee and know we won't define the behavior unexpectedly in a way that breaks their code, so they could ask for it to be guaranteed.

[RalfJung]

Hm, I still don't understand whom this comment is serving/helping. People will be asking for us to commit to something like that no matter what we write here. But sure I can try to put in a phrase along those lines. I just worry it will cause a lot more confusion than it will help people. It would certainly confuse the heck out of me without a multi-paragraph explanation.

[RalfJung]

I tried my hand at it, but honestly I don't like it. I think the text would be semantically equivalent but less confusing without that new sentence.

[nikomatsakis]

I think we should make this change, but I just want to raise the point I always raise, that simply "removing UB" isn't "always" a fine change to make, because it can make a sound API become unsound. My classic example is that rayon (and other libraries) assume that destructors will run for their local variables before the stack frame is popped. I think we eventually will want to be clear about those things we are guaranteeing (which implies a certain amount of operations that will always be UB) versus things that are UB now but which we may change.

@pnkfelix points out this is similar to the "assume *x is legal to deref" example that @chorman0773 raised.

[nikomatsakis]

@rfcbot fcp merge

I think we should make this change!

[pnkfelix]

@pnkfelix points out this is similar to the "assume *x is legal to deref" example that @chorman0773 raised.

In particular, @chorman0773 's example was a specific "the given UB list means that 'expression A is UB implies expression B is also UB', so if my method precondition includes 'expression B is well-defined', then my code can assume A is likewise well-defined." (i.e. an instance of using the contrapositive reasoning, but it relies on the given UB list remaining fixed!).

In the meeting, I waffled on whether @nikomatsakis 's example is similar or not. I think I'm still waffling now, but I'm coming back around to thinking that it indeed is such an example.

[pnkfelix]

@rfcbot fcp merge

I think we should make this change!

[pnkfelix]

(does rfcbot not monitor rust-lang/reference ...?)

[RalfJung]

I think we should make this change, but I just want to raise the point I always raise, that simply "removing UB" isn't "always" a fine change to make, because it can make a sound API become unsound. My classic example is that rayon (and other libraries) assume that destructors will run for their local variables before the stack frame is popped. I think we eventually will want to be clear about those things we are guaranteeing (which implies a certain amount of operations that will always be UB) versus things that are UB now but which we may change.

I agree in general, yes, if APIs are defined by referring to UB in negative position, like Connor's example.

The rayon case wouldn't just remove UB though, that would significantly alter the lowering from surface Rust to MIR/MiniRust. (So I don't think I see how that's an example of this issue.) And if APIs refer to "my precondition is that *x as defined in Rust 1.52 is not UB", then those should also be stable under having less UB.

(does rfcbot not monitor rust-lang/reference ...?)

It checks in once an hour.

[rfcbot]

Team member @nikomatsakis has proposed to merge this. The next step is review by the rest of the tagged team members:

• @joshtriplett
• @nikomatsakis
• @pnkfelix
• @scottmcm
• @tmandry

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

psst @nikomatsakis, I wasn't able to add the final-comment-period label, please do so.

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

psst @nikomatsakis, I wasn't able to add the finished-final-comment-period label, please do so.

[ehuss]

Thanks!