5 ms·
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
by 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 agoWhat the fuck? No. That makes as much sense as `int *i`, when `int* i` is obviously the correct (though heterodox) way.
- teo_zero 2y agoAnd how would you read the following? int* i, j; C declarations simply are not "first the type, then the variable"...
- lionkor 2y agoyou 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 agoIMHO 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 agoThe only "type" thing about the declaration above is "int", and that does get applied to all the comma-separated expressions -- so in that way the comma acts totally reasonable. People think that "int *x;" means "declare x as a pointer-to-int" but really it means "declare x such that *x (it's a code expression) is of type int." So it's a really roundabout way to say that x is a "pointer to x" while that concept of "pointer to" isn't even in the language syntax.
- jandrese 2y agoWhich makes it even worse because it is inconsistent in real world use. "long" is propagated through the comma, but * is not.
- jstimpfle 2y agoIt's not inconsistent. There are two things in a declaration: a type (here int) and an expression (here *x). If you add commas you can have multiple of the latter. That's it. Stop thinking of the star as part of the type, it isn't. Leave it with the expression to the right, and thinks make sense . It's why I always cringe when I see int* x; as opposed to int *x; There is a reason why K&R do it that way.
- jandrese 2y agoThe idea that the * isn't part of the type has always felt completely wrong to me. The entire concept of an expression modifying the type doesn't provide any benefit that I can see. The only thing the expression should be doing is giving you the chance to assign the name to the new variable you're creating. Once you define the type, which might be a pointer or not, it should be fixed. I get that this is a pretty fundamental disagreement between me and Knuth & Richie, but I think history has shown that this idea of splitting exactly one aspect of the type (if the variable is direct or a pointer) was a mistake. It's been the cause of a lot of bugs and the cases where you want to define both direct and indirect types on the same line basically don't exist. For clarity you should split those definitions up regardless of what the syntax allows. There are basically no cases where you should be writing the following code even if it is technically correct: int *pointer, direct;
- alberth 2y agoWhat’s wrong with ‘x :int*’ ?
- skupig 2y agoLet me illustrate it like this :does this look correct to you?