More precisely distinguish methods from functions and associated functions.

Author: obsgolem

text/0000-import-trait-methods.md

@@ -1,29 +1,29 @@
-- Feature Name: `import-trait-methods`
+- Feature Name: `import-trait-associated-functions`
 - Start Date: 2024-03-19
 - RFC PR: [rust-lang/rfcs#0000](https://github.com/rust-lang/rfcs/pull/0000)
 - Rust Issue: [rust-lang/rust#0000](https://github.com/rust-lang/rust/issues/0000)
 
 # Summary
 [summary]: #summary
 
-Allow importing methods from traits and then using them like regular functions.
+Allow importing associated functions from traits and then using them like regular functions. 
 
 # Motivation
 [motivation]: #motivation
 
-There has for a long time been a desire to shorten the duplication needed to access certain methods, such as `Default::default`. Codebases like [Bevy](https://github.com/bevyengine/bevy/blob/7c7d1e8a6442a4258896b6c605beb1bf50399396/crates/bevy_utils/src/default.rs#L27) provide wrapper methods to shorten this call, and a previous, now-rejected, [RFC](https://github.com/rust-lang/rust/pull/73001) aimed to provide this method as part of the standard library. This RFC was rejected with a note that there is a desire for a more general capability to import any trait method.
+There has for a long time been a desire to shorten the duplication needed to access certain associated functions, such as `Default::default`. Codebases like [Bevy](https://github.com/bevyengine/bevy/blob/7c7d1e8a6442a4258896b6c605beb1bf50399396/crates/bevy_utils/src/default.rs#L27) provide wrapper functions to shorten this call, and a previous, now-rejected, [RFC](https://github.com/rust-lang/rust/pull/73001) aimed to provide this function as part of the standard library. This RFC was rejected with a note that there is a desire for a more general capability to import any trait associated functions.
 
-Additionally, if you pull in a crate like [num_traits](https://docs.rs/num-traits/latest/num_traits/), then this feature will allow access to numeric methods such as `sin` using the `sin(x)` syntax that is more common in mathematics. More generally, it will make calls to trait methods shorter without having to write a wrapper function.
+Additionally, if you pull in a crate like [num_traits](https://docs.rs/num-traits/latest/num_traits/), then this feature will allow access to numeric functions such as `sin` using the `sin(x)` syntax that is more common in mathematics. More generally, it will make calls to trait associated functions shorter without having to write a wrapper function.
 
 # Guide-level explanation
 [guide-level-explanation]: #guide-level-explanation
 
-Importing a method from a trait is the same as importing a method from any module:
+Importing an associated functions from a trait is the same as importing a function from any module:
 ```rust
 use Default::default;
 ```
 
-Once you have done this, the method is made available in your current scope just like any other regular function.
+Once you have done this, the function is made available in your current scope just like any other regular function.
 
 ```rust
 struct S {
@@ -39,7 +39,7 @@ impl S {
 }
 ```
 
-You can also use this with trait methods that take a `self` argument:
+You can also use this with trait methods (i.e. associated functions that take a `self` argument):
 
 ```rust
 use num_traits::float::Float::{sin, cos}
@@ -49,7 +49,7 @@ fn eulers_formula(theta: f64) -> (f64, f64) {
 }
 ```
 
-Importing a method from a trait does not import the trait. If you want to call `self` methods on a trait or `impl` it, then you can import the trait as well as methods in the trait:
+Importing an associated function from a trait does not import the trait. If you want to call `self` methods on a trait or `impl` it, then you can import the trait and its associated functions in a single import statement:
 
 ```rust
 mod a {
@@ -80,7 +80,7 @@ mod b {
 }
 ```
 
-Trait methods can also be renamed when they are imported using the usual `as` syntax:
+Associated functions can also be renamed when they are imported using the usual `as` syntax:
 ```rust
 use Default::default as gimme
 
@@ -97,7 +97,7 @@ impl S {
 }
 ```
 
-You cannot import a parent trait method from a sub-trait:
+You cannot import a parent trait associated function from a sub-trait:
 
 ```rust
 use num_traits::float::Float::zero; // Error: try `use num_traits::identities::Zero::zero` instead.
@@ -114,9 +114,9 @@ fn main() {
 When 
 
 ```rust
-use Trait::method as m;
+use Trait::func as m;
 ```
-occurs, a new item `m` is made available in the function namespace of the current module. Any attempts to call this item are treated calling the trait method explicitly qualified. As always, the `as` qualifier is optional, in which case the name of the new item is identical with the name of the method in the trait. In other words, the example:
+occurs, a new item `m` is made available in the function namespace of the current module. Any attempts to call this item are treated calling the associated function explicitly qualified. As always, the `as` qualifier is optional, in which case the name of the new item is identical with the name of the associated function in the trait. In other words, the example:
 
 ```rust
 use Default::default;
@@ -149,12 +149,12 @@ impl S {
 ```
 And a call
 ```rust
-use Trait::method as m;
+use Trait::func as m;
 m(x, y, z);
 ```
 desugars to
 ```rust
-Trait::method(x, y, z);
+Trait::func(x, y, z);
 ```
 
 Additionally, the syntax
@@ -166,14 +166,14 @@ is sugar for
 use some_module::Trait;
 ```
 
-The restriction on importing parent trait methods is a consequence of this desugaring, see https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=51bef9ba69ce1fc20248e987bf106bd4 for examples of the errors you get when you try to call parent trait methods through a child trait. We will likely want better error messages than this if a user tries to import a parent method.
+The restriction on importing parent trait associated functions is a consequence of this desugaring, see https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=51bef9ba69ce1fc20248e987bf106bd4 for examples of the errors you get when you try to call parent trait associated functions through a child trait. We will likely want better error messages than this if a user tries to import a parent function.
 
 # Drawbacks
 [drawbacks]: #drawbacks
 
 Calls to `default` are less explicit than calls to `Default::default` or to `T::default`, likewise for any other trait. Some users may see this lack of explicitness as bad style.
 
-To expand on this, [the book](https://doc.rust-lang.org/book/ch07-04-bringing-paths-into-scope-with-the-use-keyword.html#creating-idiomatic-use-paths) currently recommends that methods should be called using their parent module's name:
+To expand on this, [the book](https://doc.rust-lang.org/book/ch07-04-bringing-paths-into-scope-with-the-use-keyword.html#creating-idiomatic-use-paths) currently recommends that functions should be called using their parent module's name:
 > Although both Listing 7-11 and 7-13 accomplish the same task, Listing 7-11 is the idiomatic way to bring a function into scope with use. Bringing the function’s parent module into scope with use means we have to specify the parent module when calling the function. Specifying the parent module when calling the function makes it clear that the function isn’t locally defined while still minimizing repetition of the full path.
 
 This recommendation makes the most sense when there is a possibility of ambiguity in the mind of the reader. For example, a function like `sin` is unlikely to be ambiguous, because there is only one mathematical function of that name. If a codebase is likely to be making use of multiple different implementations of `sin`, then it makes more sense to require specifically naming the one you are going to use. Similar considerations apply to traits like `Default::default`, or more generally in cases like `Frobnicator::frobnicate`.
@@ -189,32 +189,32 @@ This design is minimalist, it adds no extra syntax, instead providing a natural
 
 ## What other designs have been considered and what is the rationale for not choosing them?
 
-In [Zulip](https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Writing.20an.20RFC.20for.20.60use.20Default.3A.3Adefault.60/near/427795694), there was some discussion of whether `use Trait::method` should bring `Trait` into scope. There are three possibilities:
+In [Zulip](https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Writing.20an.20RFC.20for.20.60use.20Default.3A.3Adefault.60/near/427795694), there was some discussion of whether `use Trait::func` should bring `Trait` into scope. There are three possibilities:
 
 1. It does not - this may be unexpected, but maybe not
-2. It does - then `value.other_method_from_the_same_trait()` will work as well, this may be unexpected too
-3. It does, but only for method, that's something new for the language (need new more fine-grained tracking of traits in scope)
+2. It does - then `value.other_func_from_the_same_trait()` will work as well, this may be unexpected too
+3. It does, but only for `func`, that's something new for the language (need new more fine-grained tracking of traits in scope)
 
-Option 1 is what is proposed here. It has the simplest semantics, and I believe it best matches the user intent when they import a trait method; the desire is to make that method available as-if it were a regular function. Furthermore, it is more minimalist than the other two options in the sense that you can get to option 2 simply by importing the trait also. Option 3 seems like extra complexity for almost no added value.
+Option 1 is what is proposed here. It has the simplest semantics, and I believe it best matches the user intent when they import an associated function; the desire is to make that function available as-if it were a regular function. Furthermore, it is more minimalist than the other two options in the sense that you can get to option 2 simply by importing the trait also. Option 3 seems like extra complexity for almost no added value.
 
 ## What is the impact of not doing this?
 
-Users of the language continue to create helper methods to access trait methods with regular function syntax. More specifically, each such instance requires a minimum of three lines when using normal rust formatting, corresponding to the following example:
+Users of the language continue to create helper functions to access associated with regular function syntax. More specifically, each such instance requires a minimum of three lines when using normal rust formatting, corresponding to the following example:
 ```rust
-fn my_trait_method<T: MyTrait>(args) -> ret {
-    MyTrait::my_trait_method(args)
+fn my_trait_func<T: MyTrait>(args) -> ret {
+    MyTrait::my_trait_func(args)
 }
 ```
 Such code is boilerplate that serves nobody's time to have to write repeatedly.
 
 ## If this is a language proposal, could this be done in a library or macro instead? Does the proposed change make Rust code easier or harder to read, understand, and maintain?
 
-A library solution has already been rejected for this. This solves the same problem as a library solution in a much more general way, that doesn't require adding new library methods every time we want shorthand access to trait method names.
+A library solution has already been rejected for this. This solves the same problem as a library solution in a much more general way, that doesn't require adding new library functions every time we want shorthand access to trait function names.
 
 # Prior art
 [prior-art]: #prior-art
 
-As mentioned in [motivation], there was a rejected [RFC](https://github.com/rust-lang/rust/pull/73001) for adding a method `std::default::default` to make calling `Default::default` less repetitive. This RFC was rejected, with a desire to see something like what this RFC proposes replace it.
+As mentioned in [motivation], there was a rejected [RFC](https://github.com/rust-lang/rust/pull/73001) for adding a function `std::default::default` to make calling `Default::default` less repetitive. This RFC was rejected, with a desire to see something like what this RFC proposes replace it.
 
 [This issue](https://github.com/rust-lang/rfcs/issues/1995) also lists some further motivation for this feature.