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.

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

Pointer sigils on closures #6006

Closed
brson opened this issue Apr 22, 2013 · 4 comments
Closed

Pointer sigils on closures #6006

brson opened this issue Apr 22, 2013 · 4 comments
Labels
A-grammar Area: The grammar of Rust A-type-system Area: Type system

Comments

@brson
Copy link
Contributor

brson commented Apr 22, 2013

It continues to be very frustrating to not have closures inferred to the right type. We should be able to write ~|| { }, etc.

Nominating for a milestone.

@emberian
Copy link
Member

struct Foo {
    x: ~fn()
}

fn main() {
    let x = Foo { x: ||{} };
}

is a testcase for this aiui, and it currently works. Closing.

@alexcrichton
Copy link
Member

The case you have is for inference working, I think that this is more of an issue of:

struct Foo {
    x: ~fn()
}

fn main() {
    let y = || {};
    let x = Foo { x: y };
}

I'm not sure how long these sigils are staying around, but I'm reopening based on the non-inferred use-case not working.

@alexcrichton alexcrichton reopened this Jul 10, 2013
@catamorphism
Copy link
Contributor

@nikomatsakis says the current plan for #2202 obviates the need for this. Closing

@nikomatsakis
Copy link
Contributor

Will not be an issue with plans laid out in #2202, since one would just write proc

flip1995 pushed a commit to flip1995/rust that referenced this issue Sep 10, 2020
…ishearth

Restrict unnecessary_sort_by to non-reference, Copy types

`Vec::sort_by_key` closure parameter is `F: FnMut(&T) -> K`. The lint's suggestion destructures the `T` parameter; this was probably done to avoid different unnamed lifetimes when `K = Reverse<&T>`.

This change fixes two issues:
* Destructuring T when T is non-reference requires the type to be Copy, otherwise we would try to move from a shared reference. We make sure `T: Copy` holds.
* Make sure `T` is actually non-reference. I didn't go for destructuring multiple levels of references, as we would have to compensate in the closure body by removing derefs and maybe adding parens, which would add more complexity.

changelog: Restrict [`unnecessary_sort_by`] to non-reference, Copy types

Fixes rust-lang#6001
flip1995 pushed a commit to flip1995/rust that referenced this issue Oct 9, 2020
…hansch

unnecessary sort by: avoid dereferencing the suggested closure parameter

This change tries to simplify the solution for problematic cases but is less restrictive than  rust-lang#6006.

* We can't dereference shared references to non-Copy types, so the new suggestion does not do that. Note that this implies that the suggested closure parameter will be a reference.
* We can't take a reference to the closure parameter in the returned key, so we don't lint in those cases. This can happen either because the key borrows from the parameter (e.g. `|a| a.borrows()`), or because we suggest `|a| Reverse(a)`. If we did we would hit this error:
```
error: lifetime may not live long enough
  --> /home/ebroto/src/ebroto-clippy/tests/ui/unnecessary_sort_by.fixed:19:25
   |
19 |     vec.sort_by_key(|b| Reverse(b));
   |                      -- ^^^^^^^^^^ returning this value requires that `'1` must outlive `'2`
   |                      ||
   |                      |return type of closure is Reverse<&'2 isize>
   |                      has type `&'1 isize`

error: aborting due to previous error
```

Note that Clippy does not currently have the (MIR-based) machinery necessary to check that what is borrowed is actually the closure parameter.

changelog: [`unnecessary_sort_by`]: avoid dereferencing the suggested closure parameter

Fixes rust-lang#6001
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-grammar Area: The grammar of Rust A-type-system Area: Type system
Projects
None yet
Development

No branches or pull requests

5 participants