Prefer 'associated function' over 'static method' in msg. #31830
Conversation
|
We're actually still trying to figure out the proper terminology here. /cc @aturon @nikomatsakis |
|
The tricky part is that I see methods as a subset of all associated functions. Perhaps we should phrase it like "found the following associated functions that do not define a |
Agreed.
Although verbose, I like this. I'll wait for other opinions before making any changes. |
|
Strong 👍 on @nikomatsakis's suggested message and terminology. |
Agreed, for sure. 👍 for that wording of the diagnostic. I'm not sure that "associated functions without |
|
Hm, maybe a better way to think about it is just that methods are methods, and other The idea with the "associated foo" terminology originally is that the "main" thing the trait is being applied to is the @nikomatsakis, thoughts? |
|
Trait methods are associated items. They behave like associated constants and types in all relevant ways. They can be accessed using UFCS (= associated item notation). They dispatch through an impl. Inherent methods are a bit weird, because they behave like associated items in some respects (they are accessible via UFCS + method lookup if not static), but they don't have the trait dispatch thing Unlike associated types/constants, methods can also be used with method lookup. But that sounds to me like an "extra feature". The range structs can be used in range expressions, but they are still structs. Certainly static methods behave exactly like methods in every way expect for being accessible through method lookup. |
Oh my, did we just find a solution to the other Great Naming Bikeshed? :) |
frewsxcv
force-pushed
the
assoc-func
branch
2 times, most recently
from
ff547fa to
f41dfec
Compare
|
Updated the suggestion text. I shortened @nikomatsakis's suggestion a bit, so make sure to reread it. If people are unhappy, I can just use Niko's full text they suggested. |
| @@ -141,7 +141,8 @@ pub fn report_error<'a, 'tcx>(fcx: &FnCtxt<'a, 'tcx>, | |||
| if !static_sources.is_empty() { | |||
| err.fileline_note( | |||
| span, | |||
| "found defined static methods, maybe a `self` is missing?"); | |||
| "found the following associated functions; to be used as \ | |||
| methods, functions must have a `self` parameter"); | |||
There was a problem hiding this comment.
If we want to go with the "methods are associated functions" story, I can update this to be:
...to be used as methods, associated functions must have a
selfparameter
|
Anyone here have thoughts? |
|
📌 Commit f41dfec has been approved by |
Prefer 'associated function' over 'static method' in msg. TRPL seems to refer to 'static functions' as 'associated functions'. This terminology should be used consistently.
|
@bors: r- this failed |
Latest force push includes wrapped long lines. |
|
Now we're on to legitimate test failures 😄 |
TRPL seems to refer to 'static functions' as 'associated functions'. This terminology should be used consistently.
|
Should be okay now |
|
@bors: r+ rollup 😄 |
|
📌 Commit d9dba76 has been approved by |
Prefer 'associated function' over 'static method' in msg. TRPL seems to refer to 'static functions' as 'associated functions'. This terminology should be used consistently.
Prefer 'associated function' over 'static method' in msg. TRPL seems to refer to 'static functions' as 'associated functions'. This terminology should be used consistently.
TRPL seems to refer to 'static functions' as 'associated functions'.
This terminology should be used consistently.