They don't really have a choice, do they? If you want to add features you can either: 1) make a new reserve word, possibly breaking existing code 2) reuse a reserve word in a new context.
public function get foo():int { return 5; }
var get:int = foo;So:
class Foo
{
virtual void bar() final;
};
int final = 3;
class Foo
{
virtual void final() final;
}; var var = 1;
var select = var.ToString();
var from = from c in @select select c.GetHashCode();
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.