Pre RFC: deprecating anonymous parameters

matklad · July 19, 2016, 9:20pm

Hi! I’ve encountered the anon parameters issue a couple of times recently, so I decided to write up a pre-RFC. The main question is “Is it worth pursuing at all?” The issues is super minor, but annoys me personally a lot All the typos, grammar and language changes can be suggested directly on GitHub.

Feature Name: deprecate_anonymous_parameters
Start Date: 2016-07-19
RFC PR: (leave this empty)
Rust Issue: (leave this empty)

Summary

Currently Rust allows anonymous parameters in trait methods:

trait T {
    fn foo(i32);

    fn bar_with_default_impl(String, String) {

    }
}

This RFC proposes to deprecate this syntax. This RFC intentionally does not propose to remove this syntax.

Motivation

Anonymous parameters are a historic accident. They do not pose any significant problems, but lead to a number of annoyances.

Surprising pattern syntax in traits

trait T {
    fn foo(x: i32);        // Ok
    fn bar(&x: &i32);      // Ok
    fn baz(&&x: &&i32);    // Ok
    fn quux(&&&x: &&&i32); // Syntax error
}

Inconsistency between default implementations in traits and implementations in impl blocks

trait T {
    fn foo((x, y): (usize, usize)) { // Syntax error
    }
}

impl T for S {
    fn foo((x, y): (usize, usize)) { // Ok
    }
}

Inconsistency between method declarations in traits and in extern blocks

trait T {
    fn foo(i32);  // Ok
}

extern "C" {
    fn foo(i32); // Syntax error
}

Slightly more complicated syntax analysis for LL style parsers. The parser must guess if it currently parses a pattern or a type.
Small complications for source code analyzers (e.g. IntelliJ Rust) and potential alternative implementations.

None of these issues is significant, but they exist.

Detailed design

Removing anonymous parameters from the language is formally a breaking change. The breakage can be trivially and potentially automatically fixed by adding _: (suggested by @nagisa):

trait T {
    fn foo(_: i32);

    fn bar_with_default_impl(_: String, _: String) {

    }
}

However this is also a major breaking change from the practical point of view. Parameter names are rarely omitted, but it happens. For example, std::fmt::Display is currently defined as follows:

trait Display {
    fn fmt(&self, &mut Formatter) -> Result;
}

So the proposal is just to deprecate this syntax in the hope that the removal would become feasible and practical in the future. The hypothetical future may include:

Rust 2.0 release.
A tool to automatically fix deprecation warnings.
Storing crates on crates.io in “elaborated” syntax independent format.

Enabling deprecation early makes potential future removal easier in practice.

Drawbacks

There are a number of drawbacks:

Deprecation will require code changes across the community without bringing any noticeable immediate benefits.
It is not clear if it will ever be possible to remove this syntax entirely.

Alternatives

Status quo.
Decide on the precise removal plan prior to deprecation.
Try to solve the underlying annoyances in some other way. For example, unbounded look ahead can be used in the parser to allow both anonymous parameters and the full pattern syntax.

Unresolved questions

How often are anonymous parameters used in practice?
Is there a consensus that anonymous parameters are not a useful language feature?

matklad · July 19, 2016, 9:22pm

RFC issue: https://github.com/rust-lang/rfcs/issues/1351

jschievink · July 19, 2016, 9:50pm

I’m definitely in favor of fixing this in Rust 2.0, but practically this is such a minor issue that this doesn’t seem worth it in 1.x

matklad · July 19, 2016, 9:54pm

Yeah, that’s why I suggest only to deprecate this thing in 1.x. Deprecating “just” before 2.0 would be less effective because the time span will be shorter and because there perhaps would be a number of other deprecations at that time.

brson · July 19, 2016, 11:16pm

Seems prudent, but only if we are serious about fixing the underlying problems someday. This will be a very long deprecation period, and cause a lot of pain, so if we never fix the problem (and it just remains deprecated forever) it will be fore nothing.

Why does the first surprising pattern happen? What’s special about 3 ampersands?

matklad · July 19, 2016, 11:24pm

It's more like & and && are special cases. Most of other patterns, including &&&, are forbidden. If you allowed both arbitrary patterns and anonymous arguments, you'd need unbounded lookahead in the parser to discriminate between a type and a pattern.

matklad · July 20, 2016, 12:42am

I've coded up an inspection (with a quick fix ) for this. Running it on all the dependencies of Cargo, except the Cargo itself and standard library, gave three hits, two in rand:

github.com

rust-random/rand/blob/master/src/distributions/mod.rs#L51


      
          //! with the [`random`] function.
          //!
          //! ## Random characters
          //!
          //! [`Alphanumeric`] is a simple distribution to sample random letters and
          //! numbers of the `char` type; in contrast [`Standard`] may sample any valid
          //! `char`.
          //!
          //!
          //! # Uniform numeric ranges
          //!
          //! The [`Uniform`] distribution is more flexible than [`Standard`], but also
          //! more specialised: it supports fewer target types, but allows the sample
          //! space to be specified as an arbitrary range within its target type `T`.
          //! Both [`Standard`] and [`Uniform`] are in some sense uniform distributions.
          //!
          //! Values may be sampled from this distribution using [`Rng::sample(Range)`] or
          //! by creating a distribution object with [`Uniform::new`],
          //! [`Uniform::new_inclusive`] or `From<Range>`. When the range limits are not
          //! known at compile time it is typically faster to reuse an existing
          //! `Uniform` object than to call [`Rng::sample(Range)`].

github.com

rust-random/rand/blob/master/src/lib.rs#L658


      
          // Copyright 2018 Developers of the Rand project.
          // Copyright 2013-2017 The Rust Project Developers.
          //
          // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or
          // https://www.apache.org/licenses/LICENSE-2.0> or the MIT license
          // <LICENSE-MIT or https://opensource.org/licenses/MIT>, at your
          // option. This file may not be copied, modified, or distributed
          // except according to those terms.
          
          //! Utilities for random number generation
          //!
          //! Rand provides utilities to generate random numbers, to convert them to
          //! useful types and distributions, and some randomness-related algorithms.
          //!
          //! # Quick Start
          //!
          //! To get you started quickly, the easiest and highest-level way to get
          //! a random value is to use [`random()`]; alternatively you can use
          //! [`thread_rng()`]. The [`Rng`] trait provides a useful API on all RNGs, while
          //! the [`distributions`] and [`seq`] modules provide further
          //! functionality on top of RNGs.
          //!
          //! ```
          //! use rand::prelude::*;
          //!
          //! if rand::random() { // generates a boolean
          //!     // Try printing a random unicode code point (probably a bad idea)!
          //!     println!("char: {}", rand::random::<char>());
          //! }
          //!
          //! let mut rng = rand::thread_rng();
          //! let y: f64 = rng.random(); // generates a float between 0 and 1
          //!
          //! let mut nums: Vec<i32> = (1..100).collect();
          //! nums.shuffle(&mut rng);
          //! ```
          //!
          //! # The Book
          //!
          //! For the user guide and further documentation, please read
          //! [The Rust Rand Book](https://rust-random.github.io/book).
          
          #![doc(
              html_logo_url = "https://www.rust-lang.org/logos/rust-logo-128x128-blk.png",
              html_favicon_url = "https://www.rust-lang.org/favicon.ico",
              html_root_url = "https://rust-random.github.io/rand/"
          )]
          #![deny(missing_docs)]
          #![deny(missing_debug_implementations)]
          #![doc(test(attr(allow(unused_variables), deny(warnings))))]
          #![no_std]
          #![cfg_attr(feature = "simd_support", feature(portable_simd))]
          #![cfg_attr(docsrs, feature(doc_auto_cfg))]
          #![allow(
              clippy::float_cmp,
              clippy::neg_cmp_op_on_partial_ord,
              clippy::nonminimal_bool
          )]
          
          #[cfg(feature = "alloc")]
          extern crate alloc;
          #[cfg(feature = "std")]
          extern crate std;
          
          #[allow(unused)]
          macro_rules! trace { ($($x:tt)*) => (
              #[cfg(feature = "log")] {
                  log::trace!($($x)*)
              }
          ) }
          #[allow(unused)]
          macro_rules! debug { ($($x:tt)*) => (
              #[cfg(feature = "log")] {
                  log::debug!($($x)*)
              }
          ) }
          #[allow(unused)]
          macro_rules! info { ($($x:tt)*) => (
              #[cfg(feature = "log")] {
                  log::info!($($x)*)
              }
          ) }
          #[allow(unused)]
          macro_rules! warn { ($($x:tt)*) => (
              #[cfg(feature = "log")] {
                  log::warn!($($x)*)
              }
          ) }
          #[allow(unused)]
          macro_rules! error { ($($x:tt)*) => (
              #[cfg(feature = "log")] {
                  log::error!($($x)*)
              }
          ) }
          
          // Re-exports from rand_core
          pub use rand_core::{CryptoRng, RngCore, SeedableRng, TryCryptoRng, TryRngCore};
          
          // Public modules
          pub mod distributions;
          pub mod prelude;
          mod rng;
          pub mod rngs;
          pub mod seq;
          
          // Public exports
          #[cfg(all(feature = "std", feature = "std_rng", feature = "getrandom"))]
          pub use crate::rngs::thread::thread_rng;
          pub use rng::{Fill, Rng};
          
          #[cfg(all(feature = "std", feature = "std_rng", feature = "getrandom"))]
          use crate::distributions::{Distribution, Standard};
          
          /// Generates a random value using the thread-local random number generator.
          ///
          /// This function is simply a shortcut for `thread_rng().gen()`:
          ///
          /// -   See [`ThreadRng`] for documentation of the generator and security
          /// -   See [`Standard`] for documentation of supported types and distributions
          ///
          /// # Examples
          ///
          /// ```
          /// let x = rand::random::<u8>();
          /// println!("{}", x);
          ///
          /// let y = rand::random::<f64>();
          /// println!("{}", y);
          ///
          /// if rand::random() { // generates a boolean
          ///     println!("Better lucky than good!");
          /// }
          /// ```
          ///
          /// If you're calling `random()` in a loop, caching the generator as in the
          /// following example can increase performance.
          ///
          /// ```
          /// use rand::Rng;
          ///
          /// let mut v = vec![1, 2, 3];
          ///
          /// for x in v.iter_mut() {
          ///     *x = rand::random()
          /// }
          ///
          /// // can be made faster by caching thread_rng
          ///
          /// let mut rng = rand::thread_rng();
          ///
          /// for x in v.iter_mut() {
          ///     *x = rng.random();
          /// }
          /// ```
          ///
          /// [`Standard`]: distributions::Standard
          /// [`ThreadRng`]: rngs::ThreadRng
          #[cfg(all(feature = "std", feature = "std_rng", feature = "getrandom"))]
          #[inline]
          pub fn random<T>() -> T
          where
              Standard: Distribution<T>,
          {
              thread_rng().random()
          }
          
          #[cfg(test)]
          mod test {
              use super::*;
          
              /// Construct a deterministic RNG with the given seed
              pub fn rng(seed: u64) -> impl RngCore {
                  // For tests, we want a statistically good, fast, reproducible RNG.
                  // PCG32 will do fine, and will be easy to embed if we ever need to.
                  const INC: u64 = 11634580027462260723;
                  rand_pcg::Pcg32::new(seed, INC)
              }
          
              #[test]
              #[cfg(all(feature = "std", feature = "std_rng", feature = "getrandom"))]
              fn test_random() {
                  let _n: usize = random();
                  let _f: f32 = random();
                  let _o: Option<Option<i8>> = random();
                  #[allow(clippy::type_complexity)]
                  let _many: (
                      (),
                      (usize, isize, Option<(u32, (bool,))>),
                      (u8, i8, u16, i16, u32, i32, u64, i64),
                      (f32, (f64, (f64,))),
                  ) = random();
              }
          }

This file has been truncated. show original

and one in crossbeam:

https://github.com/aturon/crossbeam/blob/master/src/bin/bench.rs#L36

withoutboats · July 20, 2016, 7:10am

I use anonymous parameters all the time (I default to it, basically). I don’t know really have a reason - I guess I thought it was the standard thing to do. I kind of like them, but I wouldn’t mind making a change - especially because of the rather ghastly issue with pattern. It seems very bad that patterns don’t work for args in default methods.

nikomatsakis · July 21, 2016, 9:33am

Man. I really thought we had decided to remove anonymous parameters a long time ago (like, before RFCs were around) – because of the parsing ambiguities – but obviously it never happened (or else I am remembering incorrectly). I agree they are nice but I think I also agree they ought to be deprecated (or even removed, if we can get away with it).

djc · July 21, 2016, 12:33pm

Also, consider how this makes named parameters harder if we want them down the line.

matklad · July 21, 2016, 3:20pm

To throw a bit more data, Servo and all of its dependencies use anonymous parameters 34 times. Here is XML report if anyone is interested: https://gist.github.com/matklad/b40304aeaa176cd4db73716a5e315cd8

matklad · July 24, 2016, 8:19pm

RFC: https://github.com/rust-lang/rfcs/pull/1685

system · March 25, 2019, 8:26am

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.

Topic		Replies	Views
Trait method parameters now need to have names in 2018 edition	3	756	March 25, 2019
Older RFCs up for discussion this week	4	1734	March 25, 2019
Pre-RFC: Elide type or lifetime parameters in impl blocks language design	1	1182	March 25, 2019
Pre-RFC: Type parameter elision	3	1483	March 25, 2019
This week's older RFCs up for discussion	4	1982	March 25, 2019