Plan regarding the special-casing of diverging blocks

[traviscross]

We had FCPed a decision to adopt a particular Option 2 with respect to the handling of diverging blocks:

2. In Rust 2024, narrow the scope of the special casing from all diverging expressions to just those where return, break, or continue are used syntactically and no dead code (that doesn't itself diverge) follows. Do this after macro expansion at the time of type checking (so that, e.g. let _: ! = { panic!(); } also works).
   • This would promote local reasoning, making the behavior less weird.
   • It would take most of the common cases off the table for the moment.
   • We could at any later time warn about these cases also.
   • Then, if we so choose, we could then take the next step in a later edition of disallowing these.

However, we later realized that part of this couldn't work.

2. ...Do this after macro expansion at the time of type checking (so that, e.g. let _: ! = { panic!(); } also works).

While we can do this at the time of type checking, there's no way to change the expansion of panic!() such that let _: ! = { panic!(); } can work under this rule. This is due to const, e.g.:

macro_rules! my_panic {
    () => { return std::process::abort() };
}

const _: () = {
    my_panic!();
    //~^ ERROR return statement outside of function body
};

However, before we could discuss that, the PR was closed as the author no longer believes in this approach.

The general feeling of the lang team, in our recent discussions, had been agreement that, if we could do it over again, we would not adopt this special-casing. People in particular wanted to see diffs like this happen:

 pub fn abort() -> ! {
-    crate::sys::abort_internal();
+    crate::sys::abort_internal()
 }

                     let Some(id) = last.checked_add(1) else {
-                        exhausted();
+                        exhausted()
                     };

Where people had uncertainty was whether and how to adopt the churn for cases like this:

             } else {
-                return false; // other is empty
+                return false // other is empty
             };

We didn't want to take this churn in Rust 2024, especially given that prior to a recent PR to rustfmt, that tool has been adding these semicolons.

This issue is about what to do next. Do we want to address this? If so, what steps might we want to take now to better prepare us to take other steps later?

Tracking for Rust 2024:

• Tracking Issue for "don't special case diverging blocks" #123747

[traviscross]

@rustbot labels -I-lang-nominated

We discussed this in the meeting this week. Many still felt that, if we could do it over again, we wouldn't adopt this special case rule. But our concerns about churn are still there, and the special case rule does have its own peculiar kind of appeal (which is presumably why it was adopted in the first place). We wondered about how either choice would affect the way that we teach Rust, and we wished we had a better way to measure these questions of pedagogy.

Overall, we didn't see a path forward here to change the status quo.