6 ms·

syntactical disambiguation, there's already something called "the most vexing parse". C++ is full of little holes like these and getting rid of auto would surel

syntactical disambiguation, there's already something called "the most vexing parse". C++ is full of little holes like these and getting rid of auto would surely at least double compile times or at worst make parsing C++ actually impossible.

gsliepen 5y ago
Yes, those things creep up in various places. Some are fixed, like when you have std::vector<std::vector<int>> where it used to give an error because it thought >> was an operator. But recently I discovered this one: int x[100] = {}; // just a regular array int val = x[[]{return 42;}()]; // compile error! Once again, greedy parsing is the culprit; here it thinks [[ is the start of an attribute.
- klyrs 5y ago
  On one hand, nice catch... on the other hand... why do you want to do that??
pjmlp 5y ago
That is what happens when a language makes the compromise to be copy-paste compatible with https://cdecl.org/ https://cdecl.org/
- ncmncm 5y ago
  More to the point, it means the language continues to interpret header files from C libraries the same way that the C compiler always has.
  - pjmlp 5y ago
    It goes both ways, back in CFront days, and when it was picking up steam across MS-DOS, Mac OS, UNIX, among others. Unfortunely it is also an hindrance to fix some issues that prevent C++ to ever embrace safety, or better implementation of static analysers.
    - ncmncm 5y ago
      Both which ways? C was adopting C++ features before C90. Void type, function prototypes, scoped struct member tags. Declaration syntax is not an impediment to safety or to static analyzers, except insofar as it is trickier to code a parser for them.
      - pjmlp 5y ago
        It is in the sense that pointers everywhere cannot be prevented and it isn't always easy for a static analyser to actually make sense of how they are being used, as shown at some CppCon talks this year from Microsoft.
        ncmncm 5y ago
        Declaration syntax has nothing to do with "pointers everywhere".

gsliepen 5y ago

Yes, those things creep up in various places. Some are fixed, like when you have std::vector<std::vector<int>> where it used to give an error because it thought >> was an operator. But recently I discovered this one: int x[100] = {}; // just a regular array int val = x[[]{return 42;}()]; // compile error! Once again, greedy parsing is the culprit; here it thinks [[ is the start of an attribute.

klyrs 5y ago
On one hand, nice catch... on the other hand... why do you want to do that??

pjmlp 5y ago

That is what happens when a language makes the compromise to be copy-paste compatible with https://cdecl.org/ https://cdecl.org/

ncmncm 5y ago
More to the point, it means the language continues to interpret header files from C libraries the same way that the C compiler always has.
- pjmlp 5y ago
  It goes both ways, back in CFront days, and when it was picking up steam across MS-DOS, Mac OS, UNIX, among others. Unfortunely it is also an hindrance to fix some issues that prevent C++ to ever embrace safety, or better implementation of static analysers.
  - ncmncm 5y ago
    Both which ways? C was adopting C++ features before C90. Void type, function prototypes, scoped struct member tags. Declaration syntax is not an impediment to safety or to static analyzers, except insofar as it is trickier to code a parser for them.
    - pjmlp 5y ago
      It is in the sense that pointers everywhere cannot be prevented and it isn't always easy for a static analyser to actually make sense of how they are being used, as shown at some CppCon talks this year from Microsoft.
      - ncmncm 5y ago
        Declaration syntax has nothing to do with "pointers everywhere".