Type parameters that appear in a fn type should not require a Send bound

For ifaces, we enforce three criteria to ensure that regions do not escape. For fn types, we have a more simplistic requirement. This should be fixed.

Related: #2991

Is this still live? Can you reproduce?

This is still required in 0.5. But note that adding Durable (or keeping the old Owned) doesn't always clue the compiler in. Here is a test case:

// rustc --test funops.rs
extern mod std;

pub type Parser<T: Copy Durable> = fn@ (State) -> Status<T>;
pub struct State {file: @~str, text: @[char], index: uint}
pub type Status<T: Copy Durable> = Result<Succeeded<T>, Failed>;
pub struct Succeeded<T: Copy Durable> {new_state: State, value: T}
pub struct Failed {old_state: State, err_state: State, mesg: @~str}

// Used to create a function that will parse self or rhs.
pub impl<T: Copy Durable> Parser<T> : ops::BitOr<Parser<T>, Parser<T>>
{
    pure fn bitor(&self, _rhs: &Parser<T>) -> Parser<T>
    {
        |input: State|
        {
            match (*self)(input)
            {
                result::Ok(ref pass1) => 
                {
                    // This is not what the real code does...
                    result::Ok(Succeeded {new_state: pass1.new_state, value: pass1.value})
                }
                result::Err(ref failure1) =>
                {
                    result::Err(Failed {old_state: input, ..*failure1})
                }
            }
        }
    }
}

// funops.rs:17:20: 17:24 error: value may contain borrowed pointers
// funops.rs:17             match (*self)(input)
//                                  ^~~~

The reason this test case fails is that you have captured self, which is an & pointer. It is correct to complain. You would need to write: let self1 = *self outside the closure and then match self1 inside.

@graydon

@graydon it is still live.

non-critical for 0.6, de-milestoning

nmatsakis says that this is not addressed by the new borrowck. I attempted to update the test case to no avail, considering that I'm not even sure what it's supposed to demonstrate.

That test case does not demonstrate the issue. I can make up a test case that does.

Here is a test case:

fn enclose<A:Copy>(a: A) -> @fn() -> A {
  || copy a
}

fn main() { }

This test case should compile, but it yields an error reporting that a 'static bound is required.

Current error message:

foo.rs:2:14: 2:15 error: cannot capture variable of type `T`, which does not fulfill `'static`, in a bounded closure
foo.rs:2       || copy a
                       ^
foo.rs:2:14: 2:15 note: this closure's environment must satisfy `'static`
foo.rs:2       || copy a
                       ^
error: aborting due to previous error

Triage: still an issue, but copy's gone:

fn enclose<A: Clone>(a: A) -> @fn() -> A {
  || a.clone()
}
fn main() {}

2992.rs:2:5: 2:6 error: cannot capture variable of type `A`, which does not fulfill `'static`, in a bounded closure
2992.rs:2   || a.clone()
               ^
2992.rs:2:5: 2:6 note: this closure's environment must satisfy `'static`
2992.rs:2   || a.clone()
               ^
error: aborting due to previous error

Types appearing in fn types shouldn't require an owned bound

Updated terminology of title. The truth is I am a bit nervous about this change -- maybe it's better to stay conservative.

In particular we have to think carefully about variance. That said, requiring Send is definitely bogus, the right thing is 'static

This is an updated test case (since managed closures are gone):

fn enclose<A: Clone>(a: A) -> proc() -> A {
  proc() a.clone()
}
fn main() {}

Closing, this was fixed when the default bounds were removed from procedures. It is no longer required to have the Send bound.

yay, 🍰

Auto merge of rust-lang#2992 - RalfJung:ci, r=RalfJung

Refactoring contracts macro logic into separate modules (rust-lang#2992)

Merge pull request rust-lang#2992 from jyn514/videos

Navigation Menu

Repository navigation

Type parameters that appear in a fn type should not require a Send bound #2992

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Type parameters that appear in a fn type should not require a Send bound #2992

Description

Activity

graydon commented on Dec 18, 2012

jesse99 commented on Dec 22, 2012

nikomatsakis commented on Jan 3, 2013

nikomatsakis commented on Jan 3, 2013

graydon commented on Mar 22, 2013

bstrie commented on May 13, 2013

nikomatsakis commented on May 14, 2013

nikomatsakis commented on May 14, 2013

emberian commented on Jul 12, 2013

huonw commented on Sep 20, 2013

nikomatsakis commented on Mar 10, 2014

nikomatsakis commented on Mar 10, 2014

flaper87 commented on Mar 10, 2014

alexcrichton commented on Apr 2, 2014

flaper87 commented on Apr 2, 2014

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions