Deprecate anonymous parameters #1685

matklad · 2016-07-24T20:18:23Z

WaDelma · 2016-07-26T17:02:27Z

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

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.

nikomatsakis · 2016-08-05T13:35:51Z

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

strega-nil · 2016-08-05T14:36:57Z

@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 · 2016-08-05T19:17:26Z

@nikomatsakis parser lookahead is bad :(

But unavoidable.

matklad · 2016-08-05T22:28:09Z

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 · 2016-08-09T20:00:38Z

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

matklad · 2016-08-10T18:13:53Z

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 · 2016-08-11T21:26:31Z

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

nikomatsakis · 2016-08-23T17:46:31Z

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 · 2016-08-23T19:21:04Z

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.

It adds very little convenience in writing and reading code.
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 · 2016-08-27T10:50:09Z

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.

@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 rust-lang#35015. Needs crater run. cc rust-lang#35078 (comment) rust-lang#35015 rust-lang/rfcs#1685 rust-lang#35203 r? @eddyb

@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

matklad · 2016-11-12T21:47:54Z

Looks like discussion has died down. FCP maybe?

mglagla · 2016-11-28T08:32:36Z

👍 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 · 2016-11-29T03:57:33Z

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 · 2016-11-29T04:01:51Z

@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 · 2016-11-29T07:01:52Z

So is it for Rust 2.0?

petrochenkov · 2016-11-29T09:38:39Z

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 · 2016-11-29T12:02:46Z

Maybe add the lint to the Clippy first?

petrochenkov · 2016-11-29T12:20:17Z

@vi

Maybe add the lint to the Clippy first?

Whatever helps to get this out of the language eventually.

matklad · 2016-11-29T12:21:42Z

Maybe add the lint to the Clippy first?

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

est31 · 2017-03-01T12:50:50Z

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 · 2017-03-01T13:04:50Z

For them it won't be smooth.

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

porky11 · 2017-03-01T23:58:18Z

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

aturon · 2017-03-04T00:01:07Z

Let's see if this works:

@rfcbot fcp cancel

rfcbot · 2017-03-04T00:01:08Z

@aturon proposal cancelled.

aturon · 2017-03-04T00:02:15Z

@rfcbot fcp merge

(As per @nikomatsakis's comment)

rfcbot · 2017-03-04T00:02:16Z

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.

pnkfelix · 2017-03-15T17:19:58Z

text/0000-deprecate-anonymous-parameters.md

+# Motivation
+[motivation]: #motivation
+
+Anonymous parameters are a [historic accident]. They cause a number of technical


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.

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

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

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

pnkfelix · 2017-03-15T17:24:30Z

@rfcbot reviewed

rfcbot · 2017-04-19T09:24:44Z

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

rfcbot · 2017-04-29T10:05:00Z

The final comment period is now complete.

aturon · 2017-05-01T22:07:51Z

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

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

gbutler69 · 2017-06-04T04:07:42Z

@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 · 2017-06-04T10:45:04Z

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

Anonymous parameters RFC.

b5b107a

matklad mentioned this pull request Jul 24, 2016

require argument names in trait method signatures? #1351

Closed

petrochenkov mentioned this pull request Jul 24, 2016

Properly enforce the "patterns aren't allowed in foreign functions" rule rust-lang/rust#35015

Merged

nrc added the T-lang Relevant to the language team, which will review and decide on the RFC. label Jul 25, 2016

nikomatsakis self-assigned this Jul 28, 2016

petrochenkov mentioned this pull request Oct 24, 2016

Prohibit patterns in trait methods without bodies rust-lang/rust#37378

Merged

petrochenkov mentioned this pull request Mar 1, 2017

Destructuring isn't supported in default trait methods' arguments. rust-lang/rust#14267

Closed

pnkfelix reviewed Mar 15, 2017

View reviewed changes

rfcbot added the final-comment-period Will be merged/postponed/closed in ~10 calendar days unless new substational objections are raised. label Apr 19, 2017

aturon mentioned this pull request May 1, 2017

Tracking issue for RFC#1685: Deprecate anonymous parameters rust-lang/rust#41686

Closed

3 tasks

aturon merged commit cef568c into rust-lang:master May 1, 2017

est31 mentioned this pull request May 2, 2017

Add a lint to disallow anonymous parameters rust-lang/rust#41692

Merged

petrochenkov mentioned this pull request Aug 29, 2017

dyn Trait Syntax for Trait Objects: Take 2 #2113

Merged

KamilaBorowska added a commit to KamilaBorowska/enum-map that referenced this pull request Oct 8, 2017

Name trait function variables

af6fdee

According to depreciation from rust-lang/rfcs#1685

cramertj mentioned this pull request Nov 10, 2017

Implement impl Trait in argument position (RFC1951, Universal quantification) rust-lang/rust#45918

Merged

nrc mentioned this pull request Aug 10, 2018

RFC: Generalized Type Ascription #2522

Closed

Centril added the A-syntax Syntax related proposals & ideas label Nov 23, 2018

matklad mentioned this pull request Mar 4, 2019

Syntax error in trait definition rust-lang/rust-analyzer#928

Closed

matklad deleted the anon-params branch March 4, 2019 14:48

matklad mentioned this pull request Feb 4, 2020

Syntax error on trait fns with destructured args rust-lang/rust-analyzer#2847

Closed

Deprecate anonymous parameters #1685

Deprecate anonymous parameters #1685

Conversation

matklad commented Jul 24, 2016 • edited by ehuss Loading

WaDelma commented Jul 26, 2016

nikomatsakis commented Aug 5, 2016

strega-nil commented Aug 5, 2016

ticki commented Aug 5, 2016

matklad commented Aug 5, 2016

nikomatsakis commented Aug 9, 2016

matklad commented Aug 10, 2016 • edited Loading

brson commented Aug 11, 2016

nikomatsakis commented Aug 23, 2016

matklad commented Aug 23, 2016

matklad commented Aug 27, 2016

matklad commented Nov 12, 2016

mglagla commented Nov 28, 2016

nrc commented Nov 29, 2016

nrc commented Nov 29, 2016

vi commented Nov 29, 2016

petrochenkov commented Nov 29, 2016 • edited Loading

vi commented Nov 29, 2016 • edited Loading

petrochenkov commented Nov 29, 2016

matklad commented Nov 29, 2016

est31 commented Mar 1, 2017

gnzlbg commented Mar 1, 2017

porky11 commented Mar 1, 2017

aturon commented Mar 4, 2017

rfcbot commented Mar 4, 2017

aturon commented Mar 4, 2017

rfcbot commented Mar 4, 2017 • edited by withoutboats Loading

pnkfelix Mar 15, 2017

Choose a reason for hiding this comment

matklad Mar 15, 2017

Choose a reason for hiding this comment

matklad Mar 15, 2017 • edited Loading

Choose a reason for hiding this comment

nikomatsakis Apr 25, 2017

Choose a reason for hiding this comment

pnkfelix commented Mar 15, 2017

rfcbot commented Apr 19, 2017

rfcbot commented Apr 29, 2017

aturon commented May 1, 2017

gbutler69 commented Jun 4, 2017

WaDelma commented Jun 4, 2017

matklad commented Jul 24, 2016 •

edited by ehuss

Loading

matklad commented Aug 10, 2016 •

edited

Loading

petrochenkov commented Nov 29, 2016 •

edited

Loading

vi commented Nov 29, 2016 •

edited

Loading

rfcbot commented Mar 4, 2017 •

edited by withoutboats

Loading

matklad Mar 15, 2017 •

edited

Loading