Questions about syntax decisions

[Simen kjaeraas]

F. Almeida <cpp.tutoring at gmail.com> wrote:

> I have a few questions about syntax.
>
> 1) Operator overloading
>
> First of all, I find the operator overloading weird. This is because
> I'm used to C++'s syntax "operator+" and "operator+=", for example,
> instead of "opAdd" and "opAddAssign". While I understand that it
> gives plenty of room and freedom for introducing new operators in
> the future, it nonetheless feels less "natural", at the lack of a
> better word. C++ has a reserved keyword "operator" for this, why not
> using a modified syntax to this end in D? Why not using, for
> example, "operator(+)", "operator(+=)", or "operator(cast(real))"?
> This would be consistent with the simplified function template
> syntax, and make operator declarations easier to read (I find that
> reading the symbol itself is more intuitive when reading the source
> code).

The reason for the naming of operator overloads in D was to prevent
stupid overloading. That is, while the + operator might mean
concatenation, addition, and possibly other things, opAdd does not
have this ambiguity. The hope was, programmers would be discouraged
 from overloading + to mean anything other than addition.

Now, opAdd and its ilk are scheduled for deprecation. The newest
operator overloading scheme is much more C++-like, only easier to
implement for a mass of related operators:
http://digitalmars.com/d/2.0/operatoroverloading.html

As you can see, the new syntax is a template system, with the
actual operator as a string parameter. This lets you use string
mixins to cover more bases with one less code.

> 2) Operators that change context when unary or binary
>
> I noticed that for example, "~this" denotes a class destructor
> (thank you for including GC AND making it optional, btw), meaning
> that the "~" operator is a negation when used as a unary operator.
> However, it becomes a binary concatenation operator when used with
> arrays/strings, which is completely unrelated to the other use.
>
> The same applies to templates: "!" is a logical negation operator
> when used as an unary operator, but it denotes a template when
> introduced in a function declaration, for example.
>
> This can be confusing for people learning the language, especially
> if it's a first or second programming language. There are a number
> of symbols that are not used at all and could just as easily be
> used. Why not use "@"? The fact that D does not use the C macro
> preprocessor means that "#" is available, for example.

These character were chosen because not that many are available, and
because they had no binary counterpart. A negate B makes no sense.
Of the remaining character (!~@#), # is taken by compiler special
token sequences (set line number, amongst others). That leaves ~, !
and @, and frankly, A ~ B looks a lot more like concatenation to me
than does A @ B or A ! B.

As for template instantiation, we have mostly the same choices, only
not the character chosen for concatenation. Again, a choice had to
be made, and at least to me, @ implies a connection that does not
make sense, while ! does not.


This all said, there have been discussions of adding other symbols
for operator overloading, most commonly ×, for cross product.
Needless to say, this character is not easily accessible on most
keyboards, and its addition to the language has therefore not
happened.

In this vein, I gave this example two years ago:

int a = Ø; //empty set, same as "= void"
int[] b = [1,2,3,4,5,6];
a = readInt();

if (a ∈ b) { // Element of - "in"
   float c = 2.00001;
   float d =  readInt();
   writefln(c ≈ ⌈d⌉ ); // Approximately equal, ceil

   myClass c = getInstance();
   if (∃c) { // c exists, i.e. "!is null"
     writefln(√(c.foo));
   }

   ∀element∈b { // New foreach syntax!
     element *= ¼;
   }
}

I hope we don't get to see this any time soon.

-- 
Simen