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

Closure reform #2202

Closed
nikomatsakis opened this issue Apr 14, 2012 · 29 comments
Closed

Closure reform #2202

nikomatsakis opened this issue Apr 14, 2012 · 29 comments
Assignees
Labels
A-lifetimes Area: Lifetimes / regions metabug Issues about issues themselves ("bugs about bugs")
Milestone

Comments

@nikomatsakis
Copy link
Contributor

UPDATE:

This is a meta-bug now for tracking the work on completing closures. Now that #6801 has landed, the remaining pieces of work are:

ORIGINAL FOLLOWS:
We need to revamp function types in light of regions. I think fn() (the "any" function) will go away, and fn@() and fn~() will be coercable to fn&(), just as with poiners/vectors/slices/etc. Also, fn&() becomes fn&r() (that is, r is a region), though the user won't typically need to write it. We can probably leave the representation as is, though we could also tweak fn&() to not have a ref count since there will be an explicit borrowing that occurs.

@ghost ghost assigned nikomatsakis Apr 14, 2012
@catamorphism
Copy link
Contributor

@nikomatsakis Should this be an RFC, since it would change syntax?

@nikomatsakis
Copy link
Contributor Author

I don't feel it's necessary as I think it is more like a tweak. More importantly, I don't think that the work on regions makes much sense without taking these steps.

@nikomatsakis
Copy link
Contributor Author

But I am happy to prepare an RFC if you think it makes sense.

@catamorphism
Copy link
Contributor

Well, by the RFC process criteria, it is a change to the AST that isn't just refactoring, doesn't relate to numerical criteria, and would be noticed by end users. But if you think that would be overkill, it's your call.

@nikomatsakis
Copy link
Contributor Author

OK. FWIW I don't think it'd be noticed by end-users: that is, all existing syntax will remain valid, it'll just be re-interpreted to be regions-based.

@catamorphism
Copy link
Contributor

I'm confused -- you said in the original post that "fn() (the "any" function) will go away"? So isn't that making existing syntax not valid anymore? (Not trying to be antagonistic here, I just don't understand.)

@nikomatsakis
Copy link
Contributor Author

You're right, what I wrote was misleading (or perhaps just plain wrong). I meant that it would go away in the type system. You'd still be able to type fn(), it'd just be omitting the region bound (region bounds can always be omitted in all cases where they appear, such as slices etc).

@catamorphism
Copy link
Contributor

Ah ok. Then I agree, not really visible to users, hence no need for an RFC.

@catamorphism
Copy link
Contributor

Moved to 0.4.

@nikomatsakis
Copy link
Contributor Author

@catamorphism I think the beginning work here has been done. The remaining work is probably better left to 0.5. Is there some specific change you had in mind for 0.4?

@catamorphism
Copy link
Contributor

@pcwalton was saying that borrowing an @fn to a &fn results in a memory leak, and that that had something to do with this bug.

@nikomatsakis
Copy link
Contributor Author

That is true. I am not sure that we need to fix that for 0.4 though.

nikomatsakis added a commit to nikomatsakis/rust that referenced this issue Nov 6, 2012
Fixes rust-lang#1896 which was never truly fixed, just masked.
The given tests would have failed had they used `~fn()` and
not `@fn()`.  They now result in compilation errors.

Fixes rust-lang#2978.

Necessary first step for rust-lang#2202, rust-lang#2263.
nikomatsakis added a commit that referenced this issue Nov 6, 2012
Fixes #1896 which was never truly fixed, just masked.
The given tests would have failed had they used `~fn()` and
not `@fn()`.  They now result in compilation errors.

Fixes #2978.

Necessary first step for #2202, #2263.
@brendanzab
Copy link
Member

A possible test:

// http://www.paulgraham.com/accgen.html

fn accgen<T:Copy + Num>(n: &a/mut T) -> @a/fn(T) -> T {
    fn@(i: T) -> T { *n += i; *n }
}

fn main() {
    let mut n = 0;
    let f = accgen(&mut n);
    // Should print "1, 2, 3"
    io::println(fmt!("%?, %?, %?", f(1), f(1), f(1)));
}

fn@(...) certainly looks odd. I'm guessing you were forced into that syntax? ie. @fn(...) was for deprecated functionality?

@nikomatsakis
Copy link
Contributor Author

Not critical for 0.6; removing milestone

@nikomatsakis
Copy link
Contributor Author

What remains to be done:

@nikomatsakis
Copy link
Contributor Author

Oh, I forgot to add the biggest instance of work yet to be done. Making them sound! See this blog post for details:

http://smallcultfollowing.com/babysteps/blog/2013/04/30/the-case-of-the-recurring-closure/

This is blocked on #6298.

@nikomatsakis
Copy link
Contributor Author

Repurposing this issue as a metabug.

@metajack
Copy link
Contributor

nominating backwards compat

@graydon
Copy link
Contributor

graydon commented Jul 11, 2013

accepted for backwards-compatible milestone

1 similar comment
@graydon
Copy link
Contributor

graydon commented Jul 11, 2013

accepted for backwards-compatible milestone

@metajack
Copy link
Contributor

metajack commented Sep 5, 2013

visiting for triage. nothing to add.

@nikomatsakis
Copy link
Contributor Author

Update: I have a branch that does a lot of the borowck work. Semi-blocked on fixing destructor semantics.

@brson
Copy link
Contributor

brson commented Oct 8, 2013

Current plan of action:

  • make ~fn once fns
  • rename &fn to |A| -> B
  • rename extern "Rust" to fn
  • rename ~fn -> proc
  • replace various do &fn use cases with RAII
  • remove do for &fn
  • add capture clauses??
  • note: procs should carry file/line info for debugging?

@pnkfelix
Copy link
Member

cc me

@nikomatsakis
Copy link
Contributor Author

As part of this work, we need to update the kinds for function types to take into account the mutability etc of the captured values.

@nikomatsakis
Copy link
Contributor Author

Updated main comment.

@flaper87
Copy link
Contributor

updated the description to add #13621

@pcwalton
Copy link
Contributor

pcwalton commented Jun 9, 2014

I propose closing this as an outdated metabug that is currently not particularly actionable. We have several other bugs for unboxed closures.

@pnkfelix
Copy link
Member

Closing in favor of new unboxed closures approach we are now adopting: see rust-lang/rfcs#114

bors added a commit to rust-lang-ci/rust that referenced this issue Sep 22, 2022
…xes, r=RalfJung

Fix rustdoc warnings

This fixes the rustdoc warnings presented by the tool
celinval added a commit to celinval/rust-dev that referenced this issue Jun 4, 2024
Users can now select a subset of harnesses to run using `--harness` multiple times. Previously users could either run a single harness or they had to run them all.

For the example provided in rust-lang#1778:
```rust
// example.rs
#[kani::proof]
fn a() {}
#[kani::proof] 
fn b() {}
#[kani::proof] 
fn c() {std::unimplemented!();}
```

Users can select harnesses `a` and `b` by running:
```bash
$ kani example.rs --harness a --harness b
```

In case of multiple matches, Kani will run all harnesses that matches at least one of the `--harness` argument.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-lifetimes Area: Lifetimes / regions metabug Issues about issues themselves ("bugs about bugs")
Projects
None yet
Development

No branches or pull requests

9 participants