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? > > That is, I think we could make it work. I would just want to be very > sure that it would never be confusing. I think it's important that it > always be very very clear exactly what types got inferred, and how. > > Thanks for the suggestion. > > 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/CAOyqgcWKLjyQ8AsQ13%2Bwx%3DJeKR19Du0j0jfyqnKTTMUxjCitHQ%40mail.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/CAEkBMfH27abpBp75Qs9J1HemO%2B5nmQW7kX2Wj76MQ-q9DH0SwQ%40mail.gmail.com.
