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

Type analysis on branches is inconsistent depending on whether an explicit return is used #46061

Open
illicitonion opened this issue Nov 17, 2017 · 0 comments
Labels
A-inference Area: Type inference C-enhancement Category: An issue proposing an enhancement or a PR with one. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@illicitonion
Copy link

I would expect the following two snippets of code to behave the same:

extern crate futures;
use futures::future::{self, Future};

fn main() {
    println!("{}", foo().wait().unwrap());
}

fn foo() -> Box<Future<Item=String, Error=String>> {
    (|| {
        if true {
            Box::new(future::ok("foo".to_owned()))
        } else {
            bar()
        }   
    })()
}

fn bar() -> Box<Future<Item=String, Error=String>> {
    Box::new(future::ok("bar".to_owned()))
}
extern crate futures;
use futures::future::{self, Future};

fn main() {
    println!("{}", foo().wait().unwrap());
}

fn foo() -> Box<Future<Item=String, Error=String>> {
    (|| {
        if true {
            return Box::new(future::ok("foo".to_owned()));
        } else {
            bar()
        }   
    })()
}

fn bar() -> Box<Future<Item=String, Error=String>> {
    Box::new(future::ok("bar".to_owned()))
}

But in reality, the first snippet works fine, and the second fails because the typechecker cannot unify std::boxed::Box<futures::FutureResult<std::string::String, _>> with std::boxed::Box<futures::Future<Item=std::string::String, Error=std::string::String>>. Given that the typechecker can and does unify them in the first case, it seems it should be able to do the same in the second case. Whether I use an implicit or explicit return shouldn't change the type analysis being done.

@TimNN TimNN added A-inference Area: Type inference C-enhancement Category: An issue proposing an enhancement or a PR with one. labels Nov 21, 2017
@Enselic Enselic added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Sep 24, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-inference Area: Type inference C-enhancement Category: An issue proposing an enhancement or a PR with one. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

3 participants