On Fri, Jun 19, 2020 at 2:40 PM Axel Wagner <axel.wagner...@googlemail.com> wrote: > > On Fri, Jun 19, 2020 at 10:37 PM Ian Lance Taylor <i...@golang.org> wrote: >> >> On Fri, Jun 19, 2020 at 12:44 PM Brandon Bennett <benn...@gmail.com> wrote: >> > >> > I was playing around with a, probably not good, idea of what a rust-like >> > Return type would look like: https://go2goplay.golang.org/p/k0NKN9Q6Wc1 >> > >> > It seems when we are returning a specific value like Result(int) from a >> > function as in >> > >> > func myFunc(input string) Result(int) { >> > return Err(int)(ErrBadValue) >> > } >> > >> > That it would be nice if we didn't have to specify Err(int) and that it >> > could be inferred from the return type instead. >> >> If I'm reading this right, you are suggesting that because the result >> of Err is being assigned to a value of type Result(int) (via the >> return statement) we should be able to use that fact to infer the type >> argument of Err. I think that would be possible for cases where we >> are assigning to a variable of known type. It's a little more >> confusing when using := to assign to a variable whose type is not yet >> known. And it also seems unlikely to work when assigning to a >> variable of interface type. > > > I think the solution to this would probably be the same as if you use `x := > nil` - a compiler-error stating that there can't be a type assigned to the > RHS. I think it would be fine to just require type-annotations where we can't > clearly and unambiguously infer a type, as long as those cases are > understandable - the two examples seem easy to understand exceptions, so as > long as not more come up, that would still be fine IMO. > > That being said, I assume you generally see the value in more type-inference > and I trust you to come up with decent rules for this eventually :) > > I'm wondering what fundamentally separates inference of arguments from > inference of returns, FWIW. Why is it a problem if we try to infer the > return-type when assigning to an interface, but not when we try to infer the > parameter-type when passing one?
The difference is the directionality. Argument passing is like assignment. When I write "a = b", and b has an interface type, then a also has to have an interface type. So type inference for passing an argument means that passing an interface type (b) gives you an interface type (a). But for results it's the other way around. Now we know type a and we are trying to infer type b. And when a has an interface type, b can be anything that implements that interface. As you say, we can simply reject the case. We pretty much have to. But it might be confusing that we can do inference for some result type buts not others. And it's a kind of confusion that arises only for results, not for arguments. Ian -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcVxC%3D1bBoL4JcmWG8ODkyK1UXJ8%2B8id-S_LmQOtcw%3DcUw%40mail.gmail.com.
