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 https://github.com/rust-lang/rfcs/pull/2298 did not say anything about using edition dependent behavior; this was instead decided upon with an FCP in https://github.com/rust-lang/rust/issues/51934. This was done after a crater run in https://github.com/rust-lang/rust/pull/49719#issuecomment-381364742 that was green and showed 0 regressions.
After accepting the edition dependent change, @petrochenkov noted in https://github.com/rust-lang/rust/issues/51934#issuecomment-402537350 that:
As you can see in #51587 the edition-specific logic is much worse than previously implemented fallback.
However, in https://github.com/rust-lang/rust/issues/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 (https://github.com/rust-lang/rust/issues/53668#issuecomment-423144713):
Changes with negligible effects on contrived code are done very regularly, it's just nobody notices them.
In https://github.com/rust-lang/rust/issues/53668#issuecomment-423319580, @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?
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: https://github.com/rust-lang/rust/pull/49719#issuecomment-394190428
That one incident of breakage is enough to make me wonder how many other people鈥檚 code might break. Rust鈥檚 stability guarantees are one of it鈥檚 most valuable low-key features; the fact that my program will always compile forevermore is extremely useful.
I鈥檓 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.
@mark-i-m
We did see one case of breakage in the wild: https://github.com/rust-lang/rust/pull/49719#issuecomment-394190428
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鈥檓 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?
Yes, clippy was using ? in macros.
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.)
Oh, just saw #60932...
Most helpful comment
Yes, clippy was using
?in macros.