Extending ? macro repetition to Rust 2015

[Centril]

We recently stabilized the ? macro repeater "operator" proposed by @mark-i-m for Rust 2018 and it will be in Rust 1.32.

The original rust-lang/rfcs#2298 did not say anything about using edition dependent behavior; this was instead decided upon with an FCP in #51934. This was done after a crater run in #49719 (comment) that was green and showed 0 regressions.

After accepting the edition dependent change, @petrochenkov noted in #51934 (comment) that:

As you can see in #51587 the edition-specific logic is much worse than previously implemented fallback.

However, in #53668, there was a similar situation of a syntactic change for non-soundness reasons that was theoretically breaking but in practice not. In that case, @rust-lang/lang decided to accept the change for Rust 2015 and 2018 in an effort to minimize technical debt.

In #53668 @petrochenkov noted that (#53668 (comment)):

Changes with negligible effects on contrived code are done very regularly, it's just nobody notices them.

In #53668 (comment), @nikomatsakis then expanded upon the practical way in which we interpret breaking changes.

If I recall correctly, in a language team meeting not too long ago, it was suggested that we might want to reverse our decision and extend ? as a macro repetition "operator" in Rust 2015 as well. I think personally that it would be advisable; in particular, if we do so, we can avoid the technical debt in the compiler, the debt in the spec, but first and foremost, we can avoid the distinction that users must learn. Ultimately I think this is of greater practical benefit than the theoretical breakage that it would be according to crater.

Therefore I'd like to use this issue to propose an extension of ? as a macro repetition "operator" to Rust 2015.

@mark-i-m noted that they would rather not have to change the implementation again so I will not ask them to; but I'm sure someone else might want to tackle it (e.g. @petrochenkov since they were one of the first proponents of keeping it in Rust 2015 or @alexreg since they concurred with @petrochenkov).

Thoughts?

[mark-i-m]

I definitely do see the appeal here. Personally, I think I am still mildly opposed though. We did see one case of breakage in the wild: #49719 (comment)

That one incident of breakage is enough to make me wonder how many other people’s code might break. Rust’s stability guarantees are one of it’s most valuable low-key features; the fact that my program will always compile forevermore is extremely useful.

I’m also kind of hoping that this nudges people to use 2018 for new stuff and to migrate older stuff. I would love to see the compiler update to 2018 when we lock the tree to run rustfmt.

[Centril]

@mark-i-m

We did see one case of breakage in the wild: #49719 (comment)

That is a bit... vague. :) Was the breakage because clippy used the syntax ? in macros or because clippy had to make the usual changes due to changes in AST and such? Maybe @oli-obk could elaborate?

I’m also kind of hoping that this nudges people to use 2018 for new stuff and to migrate older stuff. I would love to see the compiler update to 2018 when we lock the tree to run rustfmt.

Oh sure; I agree that people should be nudged towards 2018 but surely async, try, and the module changes should be enticing enough to make that happen?

[oli-obk]

Yes, clippy was using ? in macros.

[joshtriplett]

We'd definitely want to see a crater run. If crater says this doesn't break anything, then by all means let's do this. (We should also go through a full FCP for this, and make sure it shows up in TWiR so that people shout if this might break them.)

[mark-i-m]

Oh, just saw #60932...