

Go's Declaration Syntax (2010) - dsr12
http://blog.golang.org/gos-declaration-syntax

======
simias
For those less familiar with C I'd like to point out that a common solution to
the "function pointer hell" in C is to alias the types with typedef, although
one might argue it's more a workaround than a real solution.

So the last example of function pointer taking a function pointer parameter
and returning a function pointer could look something like:

    
    
        typedef int (*return_fp_t)(int, int);
        typedef int (*param_fp_t) (int, int);
    
        return_fp_t do_stuff(param_fp_t a, int b) {
          /* ... */
        }
    

It requires coming up with new type names but it remains pretty readable in my
opinion. Also if the prototype of one of the function changes (which is pretty
common in my experience) it's easier to modify it since it's only declared
once.

------
Animats
Not mentioned in the article is the typedef problem in C.

Early C didn't have typedef, just struct. The grammar was LALR(1), and
context-independent - knowing the syntax and the reserved words, you could
parse C.

Then came typedef. Now, to parse C/C++, you must know the names of types. So,
to parse a C/C++ file, you must read and interpret all the #include files
first. This makes it hard to write tools that work on C/C++ source.

This isn't a problem with the declaration syntax of the Pascal/Modula/Ada/Go
line of languages, where declarations have the order "x int" instead of "int
x". So "go fmt" doesn't have to have all the dependencies just to clean up the
indentation.

~~~
gnuvince
Go has a similar problem: function calls and type conversions share the same
syntax (or sufficiently the same syntax). If you see `x(t)` in a Go file,
there's no way to know if that's a function call or a type conversion without
some semantic information. Also built-ins, which also look like functions,
come in to add an extra layer of difficulty.

~~~
tomp
You can interpret that as calling a coercion function that converts a value
from one type to another type. Python actually works like that.

------
userbinator
I think C declaration syntax is a bit of an acquired taste --- it looks
confusing at first but once you "get" it everything falls into place and it
feels completely natural. Arguments that it is difficult to read because it is
not "left to right" contrast with the fact that the expression syntax is not
"left to right" either in most programming languages; 2 + 3 * 4 parses as 2 +
(4 * 3) in most languages that use this syntax.

Also worth mentioning that the "clockwise/spiral rule" that this article links
to for reading C declarations is actually _wrong_ , as Linus Torvalds
helpfully points out here:
[https://plus.google.com/111049168280159033135/posts/1ZhdNwbj...](https://plus.google.com/111049168280159033135/posts/1ZhdNwbjcYF)

This is probably a better article for understanding them:
[http://www.unixwiz.net/techtips/reading-
cdecl.html](http://www.unixwiz.net/techtips/reading-cdecl.html)

~~~
GhotiFish
You know. I was working on a project last day and a horrible bug happened
where the timing system broke and spammed my console and corrupted my
database.

You know what instigated it? A precedence error.

------
vasco
It appears to me that, in the examples shown, the advantage of Go in terms of
clarity is only in the existence of the "func" keyword.

~~~
signa11
dont forget about ease of implementation as well...

~~~
leaveyou
Many times I want to program in C or try to debug some open source apps but
I'm always reminded why I didn't touch C/C++ since high school: macros,
#include, CONSTANTS, long_identifiers, ugly castings everywhere and cryptic
function pointers with the dreaded clockwise spiral rule. I still wonder how
the world would look like today if instead of C++ we would have had a C v2
binary compatible with C but with type safety, interfaces and syntax similar
to Go, or even this c2lang.org.

~~~
aikah
D?

~~~
leaveyou
D is a better C++. My feeling is that many people wanted just a better C (a
portable & extensible assembler with a good standard library?).

------
amelius
I don't mind the declarator syntax in C so much. What I _do_ mind is the way
some things are implicitly converted. For example: in

    
    
       char buffer[10];
    

the name "buffer" is a pointer to the first element of the buffer. This always
feels like a hack, because "buffer" is an array, not a pointer to an element.
I'd rather write &buffer[0]. This also feels like a hack when the buffer is
coincidentally of size 0, and buffer[0] does not exist. So I'm just left with
the feeling that something is missing in the language.

~~~
tormeh
Yeah, or that the declaration syntax of pointers are "intended to be a
mnemonic". It's syntactic sugar that, instead of being a convenience, simply
misleads you. C is a language where you need to know what's going on and
because of these weird decisions knowing how things work actively hinders you
when writing code.

int p; type nameOfInstanceOfType;

int *p; notType notNameOfInstanceOfType;

How about something sane like: "pointer p = pointer(int)" or even Scalalike
"pointer[int] p"? Pointers aren't so bad really. I think a lot of the hate for
them is because the syntax begs you to fuck up. And inevitably you do. I mean,
I just type random stuff until I get no warnings and things look like they
work. Literally. That's how I program. How many asterisks here? I dunno, I'll
just try zero through three and see if any of those work...

~~~
jeorgun

        int* p;
    

Follows the Type NameOfVar pattern, though of course it breaks for multiple
simultaneous declarations.

------
pldrnt
This hits home, I have spent many evenings designing a language that is
semantically equivalent to C++ (in fact, it's made to transpile to C++11) but
with a LALR grammar (using just flex and bison). Glad to read that none other
than Rob Pike agrees with many design choices in my language :)

------
pselbert
Rob Pike gave some details and historical footnotes about this and many other
decisions during the evolution of Go.

[http://confreaks.com/videos/3419-gophercon2014-opening-
day-k...](http://confreaks.com/videos/3419-gophercon2014-opening-day-keynote)

------
ufo
How does Go's syntax compare to Pascal and other C contemporaries?

------
jimmaswell
I wish they'd have done arr int[] instead. int[] or int* always made much more
sense to me as being the type.

------
digi_owl
f func(func(int,int) int, int) func(int, int) int

It makes sense, but at the same time it reminds me of something from the
esoteric top list at 99-bottle-of-beer.net.

------
adrianlmm
One of the main reasons is because Go syntax is designed for fast compilation.

~~~
raverbashing
I'd like to see the impact of different grammars in compilation time, which I
suspect are small.

C++ compilation is not slow because of the grammar, but because of things like
multiple includes

