public function get foo():int { return 5; }

    var get:int = foo;

    var var = 1;
    var select = var.ToString();
    var from = from c in @select select c.GetHashCode();

So:

  class Foo
  {
      virtual void bar() final;
  };

  int final = 3;

  class Foo
  {
      virtual void final() final;
  };

http://stackoverflow.com/questions/1091634/why-do-perl-varia...

(I merely state this as fact and offer no judgement!)

    sub while
    {
        print "It works!\n";
    }

    &while();

Calling it with parentheses like &foo() would make @_ empty inside of foo. (Or if you said &foo("whatever") it would pass that as @_ instead.)

    sub while
    {
            print "@_\n";
            &foo();
    }

    sub foo
    {
            print "@_\n";
    }

    &while("a","b","c");

    a b c
    (blank line)

    sub while
    {
            print "@_\n";
            &foo;
    }

    sub foo
    {
            print "@_\n";
    }

    &while("a","b","c");

    a b c
    a b c 

    @static @inline @unsigned @int ilog2(@unsigned @int x)
    {
        @for (@unsigned @int i = 0; i < 32; i++)
            @if ((x >> i) == 0)
                @return i;
        @return 32;
    }

    @autoreleasepool{
        for (int index = 0; index < 100; index++){
            int error = [MyObject performSelector:@selector(addCoolFilterToImage:)];
            if (error) {
                return 32;
            }
        }
    }

  void bar(int myArray[10+]);

As far as it being a bug waiting to happen, C already has plenty of traps like that - '=' vs '==', '&' vs '&&', and so on.

In terms of grammatical clarity, I shouldn't think it would be any more confusing than any other operators that have both unary and binary versions. By my count C already has three of those: '-', '&', '*'. The latter two are even examples where the unary meaning and the binary meaning are wholly unrelated.

Besides, it's a way of using + that is already well-established in everyday idiom. And there are semantically-related uses for + that are already well-established in computer languages, too - the Kleene +, for example, should be familiar to everybody.

In terms of how it would work for the grammar I realize this would be somewhat of a departure since it's repurposing a symbol that's normally an operator to be used in a manner that would be more like a keyword according to C syntax. . . but I think that's a detail that should be much more interesting to standards committees than it is to people who primarily just use the language. And in terms of the human factor I submit that it's much more workable than taking a word from the English language and repurposing it to mean something that's more-or-less the opposite of what it means in English.

And C programmers are already spending plenty of their time cursing the world because of those things. Let's not add more of that, shall we? ;)

= and == should have different meanings.

I also like how JavaScript has ===, although it is a little superfluous.

There are two operators, equality = and assignment :=

But where it is clear that assignment was meant, = is treated as assignment. this means you can:

    a = 5; -- exactly equivalent to a := 5 here
    if a = 6 then
        raise exception 'this should never happen';
    end if;

CLI/C++, by which Microsoft replaced Managed C++, added new operators and keywords without much regard for backwards compatibility (=without underscores).

The implication being that people value code readability over __backward __compatibility. I have no data on the popularity of Managed C++ vs CLI/C++ though. I was only a fanboy because CLI/C++ looks awesome and I generally enjoy Herb Sutter's work, but then got sucked into the Appleverse.

— Tom Duff

Not exactly the same situation, considering that compilers work.

Honestly, it might be Stockholm syndrome, but I don't find bash hard to parse at all. The only real problem I see is that people get in trouble when they try to nest quoting styles. But there's basically never any reason to do that. User-defined functions basically eliminate this (may not be POSIX compliant, but supported in all shells I know of),

I factor all my shell scripts into 2 to 10 line functions and they are super easy to maintain and are 5-10x shorter than any alternative.

[1] http://tiswww.case.edu/php/chet/bash/bashtop.html

User-defined functions are part of POSIX, but the function keyword is not. This bit me when I was porting a script from bash to dash (worth the effort on slower devices, as dash is significantly faster loading).

On bash you could do something like this:

  function foo()
  {
      echo "Foo"
  }

  bar()
  {
      echo "Bar"
  }

Duff would apparently rather read C that was written in C.

C++, on the other hand, has a horribly complex grammar. It would be unfair to say that "nobody really knows what it is," given that it has been standardized. But I think you will find that many tweaks to your code are needed when going between different C++ compilers.

I think what a lot of commenters in this thread are missing is that while the concept of a highly context-sensitive grammar seems simple, the reality is not. And having such a grammar makes it virtually impossible to have good tools.

Before some pedant reminds me that C's grammar is also context-sensitive: yes, I know. But you can parse C with lexx and yacc anyway, whereas you have no hope of doing this in C++.

[0]: Nobody would here be an obvious exaggeration, as evidenced by the above blog post.

Then again, as far as actual grammars go, I've heard C++ is bad enough that the compilers are the standard, and that if you want to be "compliant" with real world C++ code you copy every feature [1] of GCC.

[0]: http://www.amazon.com/Expert-Programming-Peter-van-Linden/dp...

[1]: ftp://ftp.trailing-edge.com/pub/rsx11freewarev2/rsx81b/374001/jargon.txt

C and C++ are good for doing low-level stuff. If you don't want to do low-level stuff, then you should not worry about them. But in that case, you might also want to avoid commenting about them :)

clang is copying gcc's features because most of them are good features, and standards bodies move slowly. This is kind of an odd thing to criticize C++ for, since a lot of newer languages don't even have a standard, but just a reference implementation. It's hard to criticize your neighbor for living in a tent when you live in a sleeping bag.

I said books. I got that vibe in general from the people I met who claimed to be C wizards. Incredibly offputting.

>C and C++ are good for doing low-level stuff. If you don't want to do low-level stuff, then you should not worry about them. But in that case, you might also want to avoid commenting about them :)

I was going to delete my original comment because reading it over it felt like a bad idea. (I don't like jumping into ignorance induced shitstorms.)[0][1]

>This is kind of an odd thing to criticize C++ for, since a lot of newer languages don't even have a standard, but just a reference implementation.

I should have put "features" in quotes. I was specifically using the definition in the old jargon file. [2] So what I really meant to say is that the compilers end up supporting each others bugs for compatibility reasons.

As for reference implementations, if the reference implementation is for all practical reasons the only implementation, then you don't need a standard.

[0]: The comments I got in response are interesting enough that I'm actually glad I didn't.

[1]: EDIT. My ignorance.

[2]: See footnote on the last post, I should have made that more clear or used different terminology.

Example?

So that's what I'm going to do unless I suddenly get the urge to go running through clangs commit log.