5 ms·

Rob Pike has some commentary on this in this blog post on Go's declaration syntax: https://go.dev/blog/declaration-syntax https://go.dev/blog/declaration-syntax

• ninkendo 2y ago
  > Go takes its cue from here, but in the interests of brevity it drops the colon This was the biggest mistake IMO. Go’s declaration syntax needs colons, it would have been 100x more readable. Compare: func foo(x int, y int) int { var sum int = x + y return sum } To: func foo(x: int, y: int): int { var sum: int = x + y return sum } The colons would have made it so much more clear to read for me.
  • pjmlp 2y ago
    So many things that it misses out, not only colons.
  • ufo 2y ago
    The lack of colons is also hard for the parser. The recursive-descent code for parsing a Go parameter declaration is quite tricky and got even trickier after they introduced generic types.
  • kbolino 2y ago
    The types stand out more with colons, certainly, but I don't find the former example any harder to read. It helps that types can only show up in certain places. Readability does suffer when multiple consecutive parameters use the same type and it's elided on all but the last, though. That's a quirk unique to Go that I haven't seen on any language using colons to specify types.
    • lpribis 2y ago
      Ada and Pascal are both languages which allow multiple consecutive parameters with the same type and also use `name: type` syntax. I agree, even when using Ada/Pascal with colons its difficult to mentally parse.
      • MaxBarraclough 2y ago
        It's subjective, but personally I've found multiple-declarations always harm readability. It's especially terrible in C and C++, where you need to be on your guard for whether all the variables are being declared with the same type or whether some are pointers. Even in languages without this quirk though, I find it still slows my comprehension. Unlike readability, conciseness of code isn't a virtue in and of itself. I see little upside to multiple-declarations, but clear downside. Language trivia: the D language does not follow C's rule, instead it guarantees all variables in a multiple-declaration statement all have identical type: int* x, y; // x and y are both pointers to ints https://dlang.org/spec/declaration.html#declaring-multiple-symbols https://dlang.org/spec/declaration.html#declaring-multiple-s...
        • kbolino 2y ago
          I think only C/C++ have this annoying quirk. C# is the same as D here and multiple variables declared in Go also all have the same type: var x, y *int // both pointers to int
  • alberth 2y ago
    Having the colon touching the type definition always made more sense to me So instead of this: func foo(x: int, y: int): int { var sum: int = x + y return sum } You’d have this instead: func foo(x :int, y :int) :int { var sum :int = x + y return sum }
    • shrimp_emoji 2y ago
      What the fuck? No. That makes as much sense as `int *i`, when `int* i` is obviously the correct (though heterodox) way.
      • teo_zero 2y ago
        And how would you read the following? int* i, j; C declarations simply are not "first the type, then the variable"...
        • lionkor 2y ago
          you would read it, spot the problem, and fix it to make it two lines. if you dont have space for that one line, switch back to punchcards
        • jandrese 2y ago
          IMHO the way comma behaves when declaring multiple variables of the same type was a mistake from day one. The sort of thing that only sticks around because it would break too much existing code to fix it. If I were in charge I'd declare the syntax deprecated in the next version of C and introduce a new character, maybe | that would do the same thing except it would propagate the pointer as you would expect. In my code I never use it. Every variable gets its own line. You might think this would blow up the declarations, but in practice it's not a problem, especially in modern C where you can move declarations down to where they're used instead of stuffing them all up at the top of the function.
          • jstimpfle 2y ago
  • knome 2y ago
    It just looks busier without any benefit to me.
  • kibwen 2y ago
    The irony is that Pike's previous language, Limbo, did use colons here: https://en.wikipedia.org/wiki/Limbo_(programming_language)#Examples https://en.wikipedia.org/wiki/Limbo_(programming_language)#E... I can only assume he removed them, not for brevity, but as a compromise for the sake of C programmers to only ask them to learn one new thing rather than two.
  • king_geedorah 2y ago
    Might as well just drop the var keyword altogether at that point. func foo(x: int, y: int): int { sum : int = x + y return x + y } With type inference the type declaration just collapses out to what you have now. func foo(x: int, y: int): int { sum := x + y return x + y } I've seen it in a few languages and it has seemed quite nice in use and appearance to me.
    • king_geedorah 2y ago
      Whoops. I've just realised those should both say return sum
  • Zardoz84 2y ago
    I personally find more readable to have the type first and no colon, and type inference : int func foo(int x, int y) { var sum = x + y return sum }
  • masfoobar 2y ago
    Odin is rather clean and seem to be consistent with the colons. foo :: proc(x : int, y : int) -> int { sum : int = x + y return sum } or foo :: proc(x : int, y : int) -> int { sum := x + y // return sum }