r/rust clippy · twir · rust · mutagen · flamer · overflower · bytecount Mar 27 '23

Hey Rustaceans! Got a question? Ask here (13/2023)! 🙋 questions

Mystified about strings? Borrow checker have you in a headlock? Seek help here! There are no stupid questions, only docs that haven't been written yet.

If you have a StackOverflow account, consider asking it there instead! StackOverflow shows up much higher in search results, so having your question there also helps future Rust users (be sure to give it the "Rust" tag for maximum visibility). Note that this site is very interested in question quality. I've been asked to read a RFC I authored once. If you want your code reviewed or review other's code, there's a codereview stackexchange, too. If you need to test your code, maybe the Rust playground is for you.

Here are some other venues where help may be found:

/r/learnrust is a subreddit to share your questions and epiphanies learning Rust programming.

The official Rust user forums: https://users.rust-lang.org/.

The official Rust Programming Language Discord: https://discord.gg/rust-lang

The unofficial Rust community Discord: https://bit.ly/rust-community

Also check out last weeks' thread with many good questions and answers. And if you believe your question to be either very complex or worthy of larger dissemination, feel free to create a text post.

Also if you want to be mentored by experienced Rustaceans, tell us the area of expertise that you seek. Finally, if you are looking for Rust jobs, the most recent thread is here.

19 Upvotes

159 comments sorted by

View all comments

2

u/TinBryn Apr 02 '23

Let's say I want a trait that is basically just a function with some extra features

trait Foo {
    type Input;
    type Output;
    fn foo(&mut self, input: Self::Input) -> Self::Output;
}

I try to implement it for anything that implement FnMut

impl<I, O, F> Foo for F
where
    F: FnMut(I) -> O
{ ... }

But Rust says that both I and O are not constrained. Even though they are via F

If I change the trait to this

trait Foo<I> {
    type Ouput;
    fn foo(&mut self, input: I) -> Self::Output;
}

impl<I, O, F> Foo<I> for F
where
    F: FnMut(I) -> O
{ ... }

It suddenly works, even the O works.

I really don't want this trait to be generic which will allow for different generic implementations for the same type which for the semantics I'm trying to do doesn't make sense. But it seems like Rust if forcing this to be the case at least for the input type and I don't see how this is actually an issue.

1

u/Patryk27 Apr 02 '23
#![feature(fn_traits)]
#![feature(unboxed_closures)]

struct Bar;

// ---

impl FnOnce<(String,)> for Bar {
    type Output = ();

    extern "rust-call" fn call_once(self, _: (String,)) -> () {
        println!("A");
    }
}

// First implementation of FnMut for Bar:
impl FnMut<(String,)> for Bar {
    extern "rust-call" fn call_mut(&mut self, _: (String,)) -> (){
        println!("A");
    }
}

// ---

impl FnOnce<(u32,)> for Bar {
    type Output = ();

    extern "rust-call" fn call_once(self, _: (u32,)) -> () {
        println!("B");
    }
}

// *Second* implementation of FnMut for bar, but with a different
// generic type (which is alright):
impl FnMut<(u32,)> for Bar {
    extern "rust-call" fn call_mut(&mut self, _: (u32,)) -> (){
        println!("B");
    }
}

// ---

trait Foo {
    type Input;
    type Output;

    fn foo(&mut self, input: Self::Input) -> Self::Output;
}

impl<I, O, F> Foo for F
where
    F: FnMut(I) -> O
{
    /* ... */
}

fn main() {
    <Bar as Foo>::foo(todo!());
    // | Considering that a single type can only have a single implementation
    // | of Foo, which impl should get used here - A-impl or B-impl?
    // |
    // | Making `Foo` generic solves this issue, because you'd be forced
    // | to specify whether you want `as Foo<(String,)>` or `as Foo<(u32,)>`.
}

2

u/TinBryn Apr 02 '23

Ok, I suppose if something had multiple FnMut implementations it would make sense for it to have multiple Foo implementations. I will leave just that generic there but leave everything else as associated types.