-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Deprecate anonymous parameters #1685
Conversation
Well I have used these quite few times when parameter name wasn't nessary to understand the purpose. Didn't even realise that they cause this much problems. |
Properly enforce the "patterns aren't allowed in foreign functions" rule Cases like `arg @ PATTERN` or `mut arg` were missing. Apply the same rule to function pointer types. Closes #35203 [breaking-change], no breakage in sane code is expected though r? @nikomatsakis This is somewhat related to rust-lang/rfcs#1685 (cc @matklad). The goal is to eventually support full pattern syntax where it makes sense (function body may present) and to support *only* the following forms - `TYPE`, `ident: TYPE`, `_: TYPE` - where patterns don't make sense (function body doesn't present), i.e. in foreign functions and function pointer types.
So I'm torn here. On the one hand, I wish we had removed them long ago, or found another way to resolve the parser ambiguities. I am not happy with the arbitrary limitations! On the other hand, those could be overcome with more parser lookahead -- maybe a cover grammar too? -- and I worry a lot about this affecting a lot of people. I'm not sure it's really feasible. (I mean, it's only a deprecation, but still.) |
@nikomatsakis parser lookahead is bad :( Deprecations are easy. We can leave them in for a long time, only taking them out when we're sure that people have stopped using them, or almost all people have stopped using them. |
But unavoidable. |
Is there perhaps any script to download the source code of all crates.io packages locally? It shouldn't be that much data, right? I may try to quantify "a lot of people". |
@matklad indeed there is https://github.com/brson/stabworld |
Here are the results:
Here is the full report: https://gist.github.com/matklad/3ab67778a15778717e8b28bb01f7bacf (warning, 700kb of XML) EDIT: Note that it does not report anonymous parameters inside macro invocations, macro definitions and macro expansions. |
I think it makes sense to deprecate, put it on the breakage wishlist, then revisit in a few years. |
I feel mildly uncomfortable with the impact of this deprecation -- particularly since it seems useful to be able to elide parameter names. The main downside of today's setup is patterns, right? So another option would be to basically require more lookahead (or a cover grammar for patterns/types, etc), so that we could support anonymous parameters without some of their downsides, right? I haven't investigated this deeply, but it seems worth considering. |
I personally think that anonymous parameters are a language feature of negative value, even if we forget about all the problems the RFC mentions.
Almost zero benefit + two syntaxes for the same thing + usual bias of not adding features < 0 |
And yet another option is to do both parser tricks and a deprecation, to allow using full range of patterns today, and to be able to remove old syntax and tricks somewhere in the distant future. |
Prohibit patterns in trait methods without bodies They are not properly type checked ```rust trait Tr { fn f(&a: u8); // <- This compiles } ``` , mostly rejected by the parser already and generally don't make much sense. This PR is kind of a missing part of rust-lang#35015. Needs crater run. cc rust-lang#35078 (comment) rust-lang#35015 rust-lang/rfcs#1685 rust-lang#35203 r? @eddyb
Prohibit patterns in trait methods without bodies They are not properly type checked ```rust trait Tr { fn f(&a: u8); // <- This compiles } ``` , mostly rejected by the parser already and generally don't make much sense. This PR is kind of a missing part of #35015. Given the [statistics from crater](#37378 (comment)), the effect of this PR is mostly equivalent to improving `unused_mut` lint. cc #35078 (comment) #35015 rust-lang/rfcs#1685 #35203 r? @eddyb
Looks like discussion has died down. FCP maybe? |
👍 on this. Whenever i'm implementing a trait, i usually copy-paste the function signature into my code. Doing this with fmt::Display often makes me stumble a bit because of the anonymous parameter, as this is surprising. |
I also want to do this, but fear the size of the breakage. Although I agree it is not nice to have alternate syntaxes around (especially when |
@rfcbot close There has not been much discussion on this thread, although it has quite a few upvotes. There seems to be a viable alternative for some of the motivation (parser lookahead), and the pain of deprecation (this would affect 7.5% of all crates on crates.io (#1685 (comment))) does not seem to be out-weighed by the benefits. OTOH, I have to say that I also don't feel strongly about this and wouldn't argue strongly against accepting, if the lang team think it is worth the user pain. |
So is it for Rust 2.0? |
I feel like if somebody just sent a PR implementing a compatibility lint instead on an RFC, this would have higher chances. 😄 |
Maybe add the lint to the Clippy first? |
Whatever helps to get this out of the language eventually. |
There's already an inspection/quick fix in IntelliJ Rust, though it's not enabled yet :) |
Just noting that some people have started getting rustc from their distro, and while I think its not the best way to obtain rust as rust is evolving at a rapid pace (nor do I want to support anything older than the latest stable in my crates), they only update it in large intervals, e.g. every 6 months, or for LTS distros every 4-5 years. For them it won't be smooth. |
By smooth I meant a "bugless" hard warning experience, not time-continuous kind of smooth. |
I like the ability to define type signatures without names, when the names aren't used anyway. |
Let's see if this works: @rfcbot fcp cancel |
@aturon proposal cancelled. |
@rfcbot fcp merge (As per @nikomatsakis's comment) |
Team member @aturon has proposed to merge this. The next step is review by the rest of the tagged teams: No concerns currently listed. Once these reviewers reach consensus, 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! See this document for info about what commands tagged team members can give me. |
# Motivation | ||
[motivation]: #motivation | ||
|
||
Anonymous parameters are a [historic accident]. They cause a number of technical |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This claim is misrepresenting the text it references.
What Niko wrote there was:
I don't believe it was intended that parameter names can be omitted in trait methods with a body
(emphasis added)
I do not think it was ever an accident that the design allowed anonymous parameters for trait methods without a body.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was referring to another part of the comment, but maybe I've misinterpreted it
I thought we planned to require parameter names in trait definitions for this reason -- but I guess that never happened?
@nikomatsakis what would be the right way to phrase this in the RFC? Or we can just drop this sentence: it does not add anything to the current situation, it just an interesting historical detail :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or perhaps I was intending to provide this link instead? https://internals.rust-lang.org/t/pre-rfc-deprecating-anonymous-parameters/3710/9?u=matklad
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Either way. I do remember discussing this at some point but -- as you say -- it never happened.
@rfcbot reviewed |
🔔 This is now entering its final comment period, as per the review above. 🔔 |
The final comment period is now complete. |
Add a lint to disallow anonymous parameters Adds a (allow by default) lint to disallow anonymous parameters, like it was decided in RFC 1685 (rust-lang/rfcs#1685). cc tracking issue rust-lang#41686
@ubsan - I would disagree with your comment:
The problem with this is, they NEVER get removed. See the situation with Java. Almost nothing that is deprecated is EVER removed (years later). Over time, it has become a problem for the language and JVM designers because they need to continue to support things that have been deprecated for years even though it keeps them from migrating the language the way they would like to easily. Deprecations should come with a promise to remove/disable the feature at a pre-defined time in the future. Ideally, deprecation should say which version the feature will be removed/disabled at the time it is deprecated. At that version it should be removed. Otherwise, the notion of deprecation is meaningless. |
As far as I understand the plan is to only remove deprecated items in rust 2.0 as removing it 1.* would be a breaking change, but I could be wrong. |
According to depreciation from rust-lang/rfcs#1685
Rendered
Issue: #1351