Deprecate anonymous parameters

[matklad]

Rendered

Issue: #1351

[WaDelma]

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.

[nikomatsakis]

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.)

[ubsan]

@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.

[ticki]

@nikomatsakis parser lookahead is bad :(

But unavoidable.

[matklad]

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".

[nikomatsakis]

@matklad indeed there is https://github.com/brson/stabworld

[matklad]

Here are the results:

416 of 5560 crates are affected.
1747 occurrences of anonymous parameters in total.

Top occurrences by crate:
149: adapton-0.2.4
101: gfx_core-0.4.0
47: mayda-0.2.1
36: unjson-0.0.4
35: zdd-0.1.0
34: ncollide_geometry-0.1.1
33: glium-0.15.0
31: ncollide_entities-0.5.0
24: delix-0.2.4
22: nalgebra-0.8.2
21: cs-0.23.1
20: oaty-0.1.0
17: stree-0.0.4
13: gfx_phase-0.6.0
12: vulkano-0.2.0
11: aster-0.0.4
11: rui-0.0.2
11: core-nightly-2015.1.7
11: podio-0.1.5
11: gfx_app-0.2.0
11: ntrusive-0.0.4
10: unctor-0.1.2
10: opal-0.1.1
10: simdop-0.1.0
09: cpython-0.0.5
09: nphysics3d-0.4.0
09: psilonz_algebra-0.0.1
09: gfx_device_dx11-0.3.0
09: specs-0.7.0
09: repl-0.7.1

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.

[brson]

I think it makes sense to deprecate, put it on the breakage wishlist, then revisit in a few years.

[nikomatsakis]

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.

[matklad]

it seems useful to be able to elide parameter names.

I personally think that anonymous parameters are a language feature of negative value, even if we forget about all the problems the RFC mentions.

1. It adds very little convenience in writing and reading code.
2. It introduces an alternative syntax for a relatively rare use case (there much more impls than traits).

Almost zero benefit + two syntaxes for the same thing + usual bias of not adding features < 0

[matklad]

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?

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.

[matklad]

Looks like discussion has died down. FCP maybe?

[mglagla]

👍 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.
Newcomers to the language also might get confused, since this is syntax that is not explained the book (I think?).

[nrc]

Looks like discussion has died down. FCP maybe?

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 _: Type is so easy to use), I fear that hitting users with a bunch of warnings about deprecation needs more motivation than it being irritating. My feeling is thus that we should not accept this RFC. Put another way, I agree that "anonymous parameters are a language feature of negative value", but that the magnitude of negative value is outweighed by the user inconvenience of deprecating.

[nrc]

@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.

[vi]

So is it for Rust 2.0?

[petrochenkov]

I feel like if somebody just sent a PR implementing a compatibility lint instead on an RFC, this would have higher chances. 😄
Even if this is not going to be removed in the close future, issuing a warning still makes sense, this won't break anyone's code unless they proactively deny warnings, and won't break dependencies.

[vi]

Maybe add the lint to the Clippy first?

[petrochenkov]

@vi

Maybe add the lint to the Clippy first?

Whatever helps to get this out of the language eventually.

[matklad]

Maybe add the lint to the Clippy first?

There's already an inspection/quick fix in IntelliJ Rust, though it's not enabled yet :)

[nikomatsakis]

@aturon

JFYI, your rfcbot command won't work until @nrc cancels the FCP.

Oh, interesting. =) Um...

[gnzlbg]

@aturon rightfully argued that:

think there's a basic disconnect here, in terms of the impact of a deprecation. While it's not technically breakage, in that the code continues to compile, the compiler is still asking you to change your code, introducing an irritation and/or churn. When that affects a large number of crates, it needs to be well-motivated and can't be done lightly (IMO).

But the "fix" for a hard deprecation warning is just #![allow(anonymous_parameters)].

As @aturon mentions, that is indeed some irritation and/or churn, but... it looks like pretty minor churn to me.

I think that the following 3 things are very important:

• 1. We should inform everybody, including those who don't even read the release notes, that something is deprecated. I don't see a way of doing this with a "soft" opt-in kind of warning. The warning must be "hard". We can start with a soft warning, that is switched to hard in the next release after ironing possible bugs with the feature, to provide a smooth experience though.
• 2. There must definitely be something in for those who fix the warnings and we should honestly tell them what that is. We don't do this just for fun, we do it for a reason, so we should tell them why they should fix it, and it must be something "tangible". For example, that bug fixes / performance fixes for the feature won't be prioritized if they complicate the compiler, and that if they opt-in to #![error(anonymous_parameters)] their code will e.g. compile faster.
• 3. We should present them their options as clearly as possible, so that they can make the best informed decision about how to proceed:
  • (First, don't overflow them with warnings, show them only the N first warnings.)
  • That they can silence the warning globally by adding #![allow(anonymous_parameters)] to the crate root, passing a flag to the compiler, or adding something to their Cargo.toml file, and reassure them that if they do this their code will still compile forever. We won't break backwards compatibility for this.
  • That they can fix the warning automatically with rustfmt --fix-warning-1234 without needing to reformat any of their code using rustfmt version > y (it is important for those who do not want to format their code with rustfmt to still be able to use it for this).
  • That they can disable the warning on a module per module basis, and fix it incrementally over time.
  • If their code compiles without warnings, we can also tell them that they can add #![error(anonymous_parameters)] to gain something for free.

[est31]

We can start with a soft warning, that is switched to hard in the next release after ironing possible bugs with the feature, to provide a smooth experience though.

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.

[gnzlbg]

For them it won't be smooth.

By smooth I meant a "bugless" hard warning experience, not time-continuous kind of smooth.

[porky11]

I like the ability to define type signatures without names, when the names aren't used anyway.

[aturon]

Let's see if this works:

@rfcbot fcp cancel

[rfcbot]

@aturon proposal cancelled.

[aturon]

@rfcbot fcp merge

(As per @nikomatsakis's comment)

[rfcbot]

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

• @aturon
• @eddyb
• @nikomatsakis
• @nrc
• @pnkfelix
• @withoutboats

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.

[pnkfelix]

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.

[matklad]

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 :)

[matklad]

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

[nikomatsakis]

Either way. I do remember discussing this at some point but -- as you say -- it never happened.

[pnkfelix]

@rfcbot reviewed

[rfcbot]

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

[rfcbot]

The final comment period is now complete.

[aturon]

This RFC has been merged -- thanks @matklad! Tracking issue is here.

[gbutler69]

@ubsan - I would disagree with your comment:

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.

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.

[WaDelma]

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.