Looking into the spec: https://go.dev/ref/spec#Return_statements ReturnStmt = "return" [ ExpressionList ] . ExpressionList = Expression { "," Expression } . ... no () here
https://go.dev/ref/spec#Function_types FunctionType = "func" Signature . Signature = Parameters [ Result ] . Result = *Parameters | Type* . Parameters = *"("* [ ParameterList [ "," ] ] *")"* . ParameterList = ParameterDecl { "," ParameterDecl } . ParameterDecl = [ IdentifierList ] [ "..." ] Type . ... a *Type* does not need () but *Parameters* needs them. But now I am puzzled. I can actually omit the variable name for the arguments: https://play.golang.com/p/g4Sz8rh06QW. This seems to be useless, but it is actually allowed, right? Am Mi., 1. Feb. 2023 um 17:04 Uhr schrieb Raphael Clancy < raphael.cla...@gmail.com>: > This is really helpful! Thank you! > > At first I assumed that it was down to 'go fmt' letting you be fairly > loose with your syntax and that you could omit parentheses where the > meaning wouldn't be ambiguous. But on closer examination, there must be > something else going on because 'return a, b' works fine and 'return (a, > b)' generates an error. But, both 'func(a string) string {}' and 'func(a > string) (string){}' work fine. > > Maybe it's because 'return' isn't really a function call and has it's own > syntax? > > On Wednesday, February 1, 2023 at 8:13:10 AM UTC-7 > axel.wa...@googlemail.com wrote: > >> Good point, didn't think of that >> >> On Wed, Feb 1, 2023, 15:30 p...@morth.org <p...@morth.org> wrote: >> >>> It would actually be ambiguous in the very place they're required. >>> >>> Consider this not completely unreasonable example: >>> https://go.dev/play/p/OL0uOnPZXju >>> >>> Also, with generics it could be ambiguous in type parameters. >>> To summarize, parentheses are needed around the return types because >>> otherwise anywhere a list of types is used, it would be ambiguous. >>> >>> Regards, >>> Per Johansson >>> >>> On Tuesday, January 31, 2023 at 8:38:46 PM UTC+1 >>> axel.wa...@googlemail.com wrote: >>> >>>> I'm not sure there really is a "reason", per se. The language could >>>> just as well have been designed not to require parentheses around the >>>> return types (at least I see no parsing ambiguity with that, though there >>>> might be) or designed to require parentheses in the return statement. It >>>> probably just felt more intuitive and readable to the designers at the >>>> time. >>>> >>>> FWIW I find it more interesting that `func() T` requires no >>>> parentheses, but `func() (S, T)` does. >>>> >>>> On Tue, Jan 31, 2023 at 5:55 PM Raphael Clancy <raphael...@gmail.com> >>>> wrote: >>>> >>>>> Hey all, I figured it was time to move to a "modern" language and I >>>>> thought I'd give go a try. So far, I'm really enjoying it. I'm just >>>>> getting >>>>> started and I had a question about parentheses. Though, I guess it's >>>>> really >>>>> about how go parses lines of code and what counts as a delimiter. >>>>> >>>>> Anyway, in the get started section on error handling >>>>> <https://go.dev/doc/tutorial/handle-errors>, why are parentheses >>>>> required around string and error here: >>>>> >>>>> func Hello(name string) (string, error) {... >>>>> >>>>> but not around message and nil here: >>>>> >>>>> return message, nil >>>>> >>>>> I tried searching a bit but I couldn't come up with anything about >>>>> such a basic topic. >>>>> >>>>> Thanks! >>>>> >>>>> -- >>>>> 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...@googlegroups.com. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/d/msgid/golang-nuts/b49dc8c2-26ea-46bc-b76a-708a2537207cn%40googlegroups.com >>>>> <https://groups.google.com/d/msgid/golang-nuts/b49dc8c2-26ea-46bc-b76a-708a2537207cn%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> -- >>> 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...@googlegroups.com. >>> >> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/golang-nuts/56d23af2-b3dd-4c59-86d4-d14d56e73a93n%40googlegroups.com >>> <https://groups.google.com/d/msgid/golang-nuts/56d23af2-b3dd-4c59-86d4-d14d56e73a93n%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- > 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/68e7ec15-5b55-4d72-b12d-fa9bcab282edn%40googlegroups.com > <https://groups.google.com/d/msgid/golang-nuts/68e7ec15-5b55-4d72-b12d-fa9bcab282edn%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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/CALWqRZrEg0GremjRjwVWMKPLPWyTOkpf5Ev0-x%2BGmkvU_rPs_Q%40mail.gmail.com.
