2 ms·

ouch is it just me that feels int i = 0; // pretty i : int = 0; // ugly i will stick to c++03 thank u very much.

by uwagar 4y ago

tricky777 4y ago
the ugly way is easier for the parser on some edge cases. https://en.m.wikipedia.org/wiki/Most_vexing_parse https://en.m.wikipedia.org/wiki/Most_vexing_parse syntax "beauty" is just a matter of how used to it you are (excl brainfuck ofcourse). Admitting this, is quite a big present one can give to him/her self.
mgraczyk 4y ago
Most new languages use postfix types. I grew up using C and C++, but now that I've learned and use Python with types and Typescript, I'm used to and prefer postfix syntax
- uwagar 4y ago
  shouldnt it then be? i: int 0 = ;
  - mgraczyk 4y ago
    No, it should read grammatically as English. int x = 0 "There is an integer x with value 0" x: int = 0 "x is an integer with value 0" x: int 0 = "x is an integer that is zero valued" The last one is awkward, the first one is harder to read.
  - tsimionescu 4y ago
    They said postfix types, not postfix syntax.
kagakuninja 4y ago
I have been using C and related languages since 1980. Switched to C++, later Java. Then about 7 years ago, I went all in on Scala, and have never looked back. Something like "i: int" is superior (at least in Scala), because the type annotation is optional. You can drop it, and just say "val i = 42". I believe it simplifies the parser as well. There is a reason many modern languages are adopting the style.
int_19h 4y ago
Now consider how this works out in C++: int i; // i is a local int int i(); // i is a global function returning an int int i(0); // i is a local int initialized to 0. Yes, there's uniform initialization now. But this whole thing was a problem in the first place because of poorly designed declarator syntax that doesn't extend well and is difficult to parse unambiguously. It can actually get worse, to the point where it's impossible to tell whether a given line of code is a declaration or not. E.g. "a<b>c" can be a declaration "a<b> c", or it can be an expression "((a < b) > c)", depending on what "a" is, exactly. This can be taken to 11 with templates: template<size_t N = sizeof(void*)> struct a { template<int> struct b {}; }; template<> struct a<sizeof(int)> { enum { b }; }; enum { c, d }; a::b<c>d; The meaning of this code now depends on whether sizeof(int)==sizeof(void*) for a given implementation on which it runs. Now, granted, this isn't the kind of thing you'd find in real world code outside of IOCCC and the likes; but it's legal, so the tooling has to be able to process it anyway. And by "tooling" I mean anything that has to parse C++ at some point - not just the compilers, but also debuggers, IDEs etc.

ouch is it just me that feels int i = 0; // pretty i : int = 0; // ugly i will stick to c++03 thank u very much.

by uwagar 4y ago

ouch is it just me that feels int i = 0; // pretty i : int = 0; // ugly i will stick to c++03 thank u very much.

the ugly way is easier for the parser on some edge cases. https://en.m.wikipedia.org/wiki/Most_vexing_parse https://en.m.wikipedia.org/wiki/Most_vexing_parse syntax "beauty" is just a matter of how used to it you are (excl brainfuck ofcourse). Admitting this, is quite a big present one can give to him/her self.

mgraczyk 4y ago

Most new languages use postfix types. I grew up using C and C++, but now that I've learned and use Python with types and Typescript, I'm used to and prefer postfix syntax

uwagar 4y ago
shouldnt it then be? i: int 0 = ;
- mgraczyk 4y ago
  No, it should read grammatically as English. int x = 0 "There is an integer x with value 0" x: int = 0 "x is an integer with value 0" x: int 0 = "x is an integer that is zero valued" The last one is awkward, the first one is harder to read.
- tsimionescu 4y ago
  They said postfix types, not postfix syntax.

kagakuninja 4y ago

I have been using C and related languages since 1980. Switched to C++, later Java. Then about 7 years ago, I went all in on Scala, and have never looked back. Something like "i: int" is superior (at least in Scala), because the type annotation is optional. You can drop it, and just say "val i = 42". I believe it simplifies the parser as well. There is a reason many modern languages are adopting the style.

int_19h 4y ago

Now consider how this works out in C++: int i; // i is a local int int i(); // i is a global function returning an int int i(0); // i is a local int initialized to 0. Yes, there's uniform initialization now. But this whole thing was a problem in the first place because of poorly designed declarator syntax that doesn't extend well and is difficult to parse unambiguously. It can actually get worse, to the point where it's impossible to tell whether a given line of code is a declaration or not. E.g. "a<b>c" can be a declaration "a<b> c", or it can be an expression "((a < b) > c)", depending on what "a" is, exactly. This can be taken to 11 with templates: template<size_t N = sizeof(void*)> struct a { template<int> struct b {}; }; template<> struct a<sizeof(int)> { enum { b }; }; enum { c, d }; a::b<c>d; The meaning of this code now depends on whether sizeof(int)==sizeof(void*) for a given implementation on which it runs. Now, granted, this isn't the kind of thing you'd find in real world code outside of IOCCC and the likes; but it's legal, so the tooling has to be able to process it anyway. And by "tooling" I mean anything that has to parse C++ at some point - not just the compilers, but also debuggers, IDEs etc.