News for hackers. Stuff that matters.
Re:The first new build of Circle, a new C++20 compiler, sinc... by tdiff on Monday January 23, 2023 @07:32AM (#34488053)
Guess it simplifies parsing, e.g. infamous "most vexing parse" etc.
Re:The first new build of Circle, a new C++20 compiler, sinc... by FpUser on Monday January 23, 2023 @07:40AM (#34488111)
Convenience should be for users of a tool not creator.
Re:The first new build of Circle, a new C++20 compiler, sinc... by int_19h on Monday January 23, 2023 @03:58PM (#34494948)
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.

Re:The first new build of Circle, a new C++20 compiler, sinc... by FpUser on Monday January 23, 2023 @09:39PM (#34498428)
>"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++.

Re:The first new build of Circle, a new C++20 compiler, sinc... by int_19h on Tuesday January 24, 2023 @05:49AM (#34502034)
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.
Re:The first new build of Circle, a new C++20 compiler, sinc... by FpUser on Tuesday January 24, 2023 @07:10AM (#34502604)
I shall admit my defeat ;)