Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Rob Pike wrote a rationale for Go's type syntax here: https://blog.golang.org/gos-declaration-syntax He seems to agree with you.

"One merit of this left-to-right style is how well it works as the types become more complex." ... "Overall, though, we believe Go's type syntax is easier to understand than C's, especially when things get complicated." ... "Go's declarations read left to right. It's been pointed out that C's read in a spiral! See The "Clockwise/Spiral Rule" by David Anderson."



I am still of the opinion that not putting some sort of visual break between a variable name and the type is somewhat unpleasant. Almost every other language uses a colon to make these easier to visually parse.


And having to type a colon makes using this kind of typing more annoying.


I'm curious if you also believe the same about key/value separation in map literals - it could also be done with juxtaposition, as in e.g. Clojure, but Go still uses a colon there.


Previously: https://news.ycombinator.com/item?id=12775735

Apparently the Spiral Rule is not entirely correct.


In C the type of a variable is "variable-centric" rather than "type-centric": it's denoted by syntax akin to the one you would use to use the variable. So if you have

  int (*arr)[2]
that means "if you dereference arr, the expression represents an array of 2 elements". So, for example, if you want a pointer to a function that returns a pointer to an array of two elements, how do you denote it? You'd go step-by-step based on how you would use it:

  int a[2]
  int (*f)[2]
  int (*(*fp)())[2]
Once you understand this, the typing syntax should make sense, and you see that any description like spirals or whatever misses the big picture.


Main issue here is that such syntax is write-only. Every time you read this expression later you have to go through the mental gimnastics you've just described to understand it.


I'm not endorsing it!


So how do I declare a function pointer for a function that takes two arguments and returns a value, all of which are function pointers of that same type?


I can't tell if this is a rhetorical question or not, but you can't have recursive typedefs in C.


I can't tell either. :-)

The grammar seems to prevent recursive typedefs, but I've never seen it spelled out that you can't have them. This has caused me trouble on occasion.

I can't even seem to solve this with gcc's non-standard __typeof__ extension. I was halfway expecting to crash or hang the compiler.


I mean if you take the grammar to be part of the official language specification and you believe it prohibits recursive typedefs then isn't that sufficient? It seems a bit like saying it causes you trouble on occasion that they never explicitly spelled out that 'deftype' isn't a synonym for 'typedef'? I would've assumed that if something is not valid in the grammar then it's not valid in the language described by it.


Well the hope is that somehow I'm misunderstanding the grammar... because there simply must be a way to do this. How can the language committee leave this flaw unfixed?


> there simply must be a way to do this.

Why? This seems completely baseless.

> How can the language committee leave this flaw unfixed?

Same way many languages like C++, C#, Java, VB etc. left this "flaw" unfixed.


void* </s>


aka, "declaration follows use"


> especially when things get complicated

I think that's a strange rationale and it doesn't fit the philosophy promoted by golang otherwise, which is that we should optimize for the 80% or 90% cases.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: