3 ms·

Guess it simplifies parsing, e.g. infamous "most vexing parse" etc.

by tdiff 4y ago

FpUser 4y ago
Convenience should be for users of a tool not creator. And if it is fn than why not function instead. This single / double character constructs / modifiers in my opinion reduce readability. When reading Rust code apostrophe modifier for example is hard to see.
- int_19h 4y ago
  Tools are themselves "users" of syntax, and if you design a language without regard for their convenience at all, you end up in situations where e.g. code completion doesn't work because the syntax forces a forward reference (think of stuff like SELECT .. FROM ..), performance issues etc. And to the end users, the convenience should be considered as an aggregate metric: it's not just about writing code, but also about reading code, compiling code, debugging code etc. You have to optimize for UX across the board, which sometimes necessitates compromises in some of those areas. And the declaration syntax for C++ is so bad that, in the most general case, you can't even reliably tell if it's a declaration or not without knowing the compiler that'll process it! Consider: template<size_t N = sizeof(void*)> struct a { template<int> struct b {}; }; template<> struct a<sizeof(int)> { enum { b }; }; enum { c, d }; struct test : a<> { friend int main() { b<c>d; // declaration or expression? &d; // error or ok? } }; The first commented line above parses either as: b<c> d; // local variable or as: ((b < c) > d); // expression depending on whether sizeof(int)==sizeof(void*) on that particular implementation. Consequently, the following &d is either legal or not, depending on whether it's trying to take the address of a local or of an enum constant. That alone is, to me, sufficient reason to believe that changing it to Pascal-style "name: type" declarations, which are unambiguous, benefits both tools and humans, even if it's slightly more verbose.
  - FpUser 4y ago
    >"That alone is, to me, sufficient reason to believe that changing it to Pascal-style "name: type" declarations, which are unambiguous, benefits both tools and humans, even if it's slightly more verbose." I am not against it. It is a different language altogether though. We were talking about "fixing" C++ while it is still being C++.
    - int_19h 4y ago
      As it happens, C++ has already adopted "auto f() -> T" function declaration syntax many years ago in addition to "T f()", so this is arguably just a more streamlined take on that. I don't see how it makes it less C++, since conceptually everything is the same.
      - FpUser 4y ago
        I shall admit my defeat ;)

Guess it simplifies parsing, e.g. infamous "most vexing parse" etc.

by tdiff 4y ago

Guess it simplifies parsing, e.g. infamous "most vexing parse" etc.

Convenience should be for users of a tool not creator. And if it is fn than why not function instead. This single / double character constructs / modifiers in my opinion reduce readability. When reading Rust code apostrophe modifier for example is hard to see.

int_19h 4y ago
Tools are themselves "users" of syntax, and if you design a language without regard for their convenience at all, you end up in situations where e.g. code completion doesn't work because the syntax forces a forward reference (think of stuff like SELECT .. FROM ..), performance issues etc. And to the end users, the convenience should be considered as an aggregate metric: it's not just about writing code, but also about reading code, compiling code, debugging code etc. You have to optimize for UX across the board, which sometimes necessitates compromises in some of those areas. And the declaration syntax for C++ is so bad that, in the most general case, you can't even reliably tell if it's a declaration or not without knowing the compiler that'll process it! Consider: template<size_t N = sizeof(void*)> struct a { template<int> struct b {}; }; template<> struct a<sizeof(int)> { enum { b }; }; enum { c, d }; struct test : a<> { friend int main() { b<c>d; // declaration or expression? &d; // error or ok? } }; The first commented line above parses either as: b<c> d; // local variable or as: ((b < c) > d); // expression depending on whether sizeof(int)==sizeof(void*) on that particular implementation. Consequently, the following &d is either legal or not, depending on whether it's trying to take the address of a local or of an enum constant. That alone is, to me, sufficient reason to believe that changing it to Pascal-style "name: type" declarations, which are unambiguous, benefits both tools and humans, even if it's slightly more verbose.
- FpUser 4y ago
  >"That alone is, to me, sufficient reason to believe that changing it to Pascal-style "name: type" declarations, which are unambiguous, benefits both tools and humans, even if it's slightly more verbose." I am not against it. It is a different language altogether though. We were talking about "fixing" C++ while it is still being C++.
  - int_19h 4y ago
    As it happens, C++ has already adopted "auto f() -> T" function declaration syntax many years ago in addition to "T f()", so this is arguably just a more streamlined take on that. I don't see how it makes it less C++, since conceptually everything is the same.
    - FpUser 4y ago
      I shall admit my defeat ;)