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

Tracking issue for Fn traits (`unboxed_closures` feature) #29625

Open
aturon opened this Issue Nov 5, 2015 · 9 comments

Comments

Projects
None yet
10 participants
@aturon
Member

aturon commented Nov 5, 2015

Tracks stabilization for the Fn* traits.

Random bugs:

  • #42736 -- foo() sugar doesn't work where you have &Foo: FnOnce
  • #45510 -- trait-based dispatch not working
@nagisa

This comment has been minimized.

Show comment
Hide comment
@nagisa

nagisa May 13, 2016

Contributor

Inability to delegate calls to other FnOnce implementors like this:

struct A<T>(T);

impl<T, Args> FnOnce<Args> for A<T>
where T: FnOnce<Args> {
    type Output = <T as FnOnce<Args>>::Output;
    fn call_once(self, args: Args) -> Self::Output { FnOnce::call_once(self.0, args) }
}

is the reason I have a safety issue in libloading.

Contributor

nagisa commented May 13, 2016

Inability to delegate calls to other FnOnce implementors like this:

struct A<T>(T);

impl<T, Args> FnOnce<Args> for A<T>
where T: FnOnce<Args> {
    type Output = <T as FnOnce<Args>>::Output;
    fn call_once(self, args: Args) -> Self::Output { FnOnce::call_once(self.0, args) }
}

is the reason I have a safety issue in libloading.

@petrochenkov

This comment has been minimized.

Show comment
Hide comment
@petrochenkov

petrochenkov Jul 12, 2016

Contributor

FnOnce::Output is stabilized in #34365

Contributor

petrochenkov commented Jul 12, 2016

FnOnce::Output is stabilized in #34365

@nrc

This comment has been minimized.

Show comment
Hide comment
@nrc

nrc Aug 17, 2016

Member

Could someone summarise what is blocking stabilisation here please?

Member

nrc commented Aug 17, 2016

Could someone summarise what is blocking stabilisation here please?

@nagisa

This comment has been minimized.

Show comment
Hide comment
@nagisa

nagisa Aug 18, 2016

Contributor

@nrc uncertainty about Args being the right thing given the possibility of variadic generics coming along around 2030 is the most major reason this is unstable.

Contributor

nagisa commented Aug 18, 2016

@nrc uncertainty about Args being the right thing given the possibility of variadic generics coming along around 2030 is the most major reason this is unstable.

@aturon

This comment has been minimized.

Show comment
Hide comment
@aturon

aturon Aug 27, 2016

Member

@nrc also possibly some questions around the inheritance relationship, see #19032

Member

aturon commented Aug 27, 2016

@nrc also possibly some questions around the inheritance relationship, see #19032

@brunoczim

This comment has been minimized.

Show comment
Hide comment
@brunoczim

brunoczim Jan 18, 2018

There should be a way of casting fn(A) -> B to Fn(A) -> B

There should be a way of casting fn(A) -> B to Fn(A) -> B

@SimonSapin

This comment has been minimized.

Show comment
Hide comment
@SimonSapin

SimonSapin Jan 18, 2018

Contributor

@brunoczim That coercion already happens implicitly, but Fn() as a type is a trait object so it needs to be behind some kind of pointer:

use std::rc::Rc;
fn main() {
    let _: &Fn() = &main;
    let _: Box<Fn()> = Box::new(main);
    let _: Rc<Fn()> = Rc::new(main);
}
Contributor

SimonSapin commented Jan 18, 2018

@brunoczim That coercion already happens implicitly, but Fn() as a type is a trait object so it needs to be behind some kind of pointer:

use std::rc::Rc;
fn main() {
    let _: &Fn() = &main;
    let _: Box<Fn()> = Box::new(main);
    let _: Rc<Fn()> = Rc::new(main);
}
@Michael-F-Bryan

This comment has been minimized.

Show comment
Hide comment
@Michael-F-Bryan

Michael-F-Bryan Apr 2, 2018

One issue we've been discussing on TheDan64/inkwell#5 is the ability to mark something as unsafe to use. What about having an UnsafeFn marker trait which could be used to tell the compiler a callable is unsafe to call?

For context, inkwell is a wrapper around LLVM and we're trying to figure out how to return a function pointer to a JIT compiled function, when calling the function is fundamentally unsafe for the same reasons FFI code is unsafe to call.

One issue we've been discussing on TheDan64/inkwell#5 is the ability to mark something as unsafe to use. What about having an UnsafeFn marker trait which could be used to tell the compiler a callable is unsafe to call?

For context, inkwell is a wrapper around LLVM and we're trying to figure out how to return a function pointer to a JIT compiled function, when calling the function is fundamentally unsafe for the same reasons FFI code is unsafe to call.

@CodeSandwich

This comment has been minimized.

Show comment
Hide comment
@CodeSandwich

CodeSandwich May 4, 2018

There is another reason to add UnsafeFn: currently unsafe fns don't implement Fn. There is no way to pass unsafe fn as a function argument, they are second class citizen: example.

UnsafeFn could be implemented for things implementing Fn, so Fns can be used wherever UnsafeFn is required. There probably also should be UnsafeFnMut and UnsafeFnOnce.

CodeSandwich commented May 4, 2018

There is another reason to add UnsafeFn: currently unsafe fns don't implement Fn. There is no way to pass unsafe fn as a function argument, they are second class citizen: example.

UnsafeFn could be implemented for things implementing Fn, so Fns can be used wherever UnsafeFn is required. There probably also should be UnsafeFnMut and UnsafeFnOnce.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment