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

Manually specify type info #27

Open
8BitMate opened this issue Nov 11, 2019 · 2 comments
Open

Manually specify type info #27

8BitMate opened this issue Nov 11, 2019 · 2 comments

Comments

@8BitMate
Copy link
Contributor

There are cases where type inference is impossible, even when fully qualified paths to every method/function is given. In those cases the macro author need to specify the type.
Consider this function:

fn cmp_str() -> bool {
    let __v0 = ::std::str::FromStr::from_str("str");
    let __v1 = ::std::result::Result::unwrap(__v0);
    let __v2 = ::std::string::ToString::to_string("str");
    let __v3 = ::std::cmp::PartialEq::eq(&__v2, &__v1);
    __v3
}

In this case it can't infer the type of __v0, since it can't know what the Self type of FromStr is. This instance could be fixed if we allowed specifying the Self type. We could then change the first line to:

let __v0 = <::std::string::String as ::std::str::FromStr>::from_str("str");

A separate issue can arise if we invoke a trait function with generic parameters, and one of the parameters needs to be specified.

I'm not sure what would be a good interface to deal with this issue. We might generate INVOKE_WITH_SELF. where the first parameter is a Type or RuntimeType parameter, and the rest works like regular INVOKE. We might alternatively have a set_self function that deals with this, that can be used after a normal INVOKE. Unfortunately, this only deals with the Self issue, and not generics in general.

Any suggestions here would be helpful.

@8BitMate
Copy link
Contributor Author

I also think this functionality should be opt-in, as it as possible to do complete type inference in a lot of cases.

@dtolnay
Copy link
Owner

dtolnay commented Nov 12, 2019

I think this can happen much later, as part of gradually expanding the scope of macros that reflect is suitable for. In the early stage I think it's fine to focus on just simple macros like Debug where very basic inference is enough to generate correct code. Once we have a robust solution there, we can move on to the more complex use cases.

For a possible API for manual type info, we could support specifying the type of any Value as needed, and the types of a function's generic parameters and Self type.

let result = RUNTIME::std::str::FromStr::from_str.INVOKE(input);
let value = RUNTIME::std::result::Result::unwrap.INVOKE(result);
value.set_type(my_field.get_type());  // fn set_type(&self, ty: reflect::Type)
// for a function like `fn huh<A, B, C>(arg: D)`
// where set_type isn't sufficient to determine all the parameters:
RUNTIME::path::to::huh
    .generic(type_a, type_b, type_c)
    .INVOKE(value_d);
// to get `<::std::string::String as ::std::str::FromStr>::from_str(input)`
RUNTIME::std::str::FromStr::from_str
    .impl_for(RUNTIME::std::string::String)
    .INVOKE(input);

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants