> > > 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 > but not others. And it's a kind of confusion that arises only for > results, not for arguments. It is a situation that seems easily explainable, so teachable. The single possibility case "specific = specific" says this about inference: unknown = specific, infer unknown matches specific specific = unknown, infer unknown matches specific The multiple possibility cases are as you say: unknown = nonspecific, infer unknown matches nonspecific (identical interfaces) nonspecific = unknown, no inference possible; unknown may be any of multiple possibilities. The teachable maxim is: "can infer from single choice; cannot infer from multiple choices" On Fri, Jun 19, 2020 at 4:03 PM Ian Lance Taylor <i...@golang.org> wrote: > 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 > . > -- *Michael T. jonesmichael.jo...@gmail.com <michael.jo...@gmail.com>* -- 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/CALoEmQz8YhVnkgf_Ca%2BQo7fSLCuyHQfyKyKwiTLJrA-bQcfgEA%40mail.gmail.com.
