Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Uniform function call syntax #11938

Closed
brson opened this issue Jan 30, 2014 · 9 comments
Closed

Uniform function call syntax #11938

brson opened this issue Jan 30, 2014 · 9 comments
Labels
A-codegen Area: Code generation A-type-system Area: Type system P-medium Medium priority

Comments

@brson
Copy link
Contributor

brson commented Jan 30, 2014

Don't see an issue for this. Would like to be able to treat methods like any other function, by providing self explicitly.
@brson brson mentioned this issue Jan 30, 2014
Closed
@lilyball
Copy link
Contributor

cc me

@brson
Copy link
Contributor Author

brson commented Jan 30, 2014

Nominating since this could block #11878.

@nikomatsakis
Copy link
Contributor

cc me

@pnkfelix
Copy link
Member

pnkfelix commented Feb 6, 2014

Assigning P-high, but not 1.0.

@nikomatsakis
Copy link
Contributor

Thanks to @eddyb's tireless efforts, this should be relatively close
to reality: in simple cases, I imagine all we have to do is update
resolve. Not sure if there are more complex cases.

@ben0x539
Copy link
Contributor

Is this about being able to write SomeTrait::trait_method(self_ptr, ...) and SomeType::inherent_method(self_ptr, ...) or for first_argument.some_free_function(...) like in D?

@Kimundi
Copy link
Member

Kimundi commented Feb 22, 2014

@ben0x539: The first two.

@brson brson mentioned this issue Mar 11, 2014
Closed
@alexcrichton alexcrichton mentioned this issue Apr 28, 2014
Closed
@japaric
Copy link
Member

japaric commented Oct 14, 2014

The UFCS RFC has been accepted, and #16293 is tracking its implementation.

Should this be closed in favor of that issue?

@nrc
Copy link
Member

nrc commented Oct 15, 2014

Closing as a dup of #16293

@nrc nrc closed this as completed Oct 15, 2014
@eternaleye eternaleye mentioned this issue Apr 4, 2015
Closed
flip1995 pushed a commit to flip1995/rust that referenced this issue Dec 28, 2023
@bors
Auto merge of rust-lang#11938 - GuillaumeGomez:unconditional_recursio…
9907b90 
…n, r=llogiq

Add new `unconditional_recursion` lint

Currently, rustc `unconditional_recursion` doesn't detect cases like:

```rust
enum Foo {
    A,
    B,
}

impl PartialEq for Foo {
    fn eq(&self, other: &Self) -> bool {
        self == other
    }
}
```

This is because the lint is currently implemented only for one level, and in the above code, `self == other` will then call `impl PartialEq for &T`, escaping from the detection. The fix for it seems to be a bit tricky (I started investigating potential solution to add one extra level of recursion [here](https://github.com/rust-lang/rust/compare/master...GuillaumeGomez:rust:trait-impl-recursion?expand=1) but completely broken at the moment).

I expect that this situation will remain for a while. In the meantime, I think it's acceptable to check it directly into clippy for the time being as a lot of easy cases like this one can be easily checked (next I plan to extend it to cover other traits like `ToString`).

changelog: Add new `unconditional_recursion` lint
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
A-codegen Area: Code generation A-type-system Area: Type system P-medium Medium priority
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
8 participants
@lilyball @ben0x539 @brson @nikomatsakis @pnkfelix @nrc @Kimundi @japaric