digitalmars.D.learn - Questions about syntax decisions
- F. Almeida (39/39) May 19 2010 Dear all,
- Simen kjaeraas (48/76) May 19 2010 The reason for the naming of operator overloads in D was to prevent
- F. Almeida (7/7) May 19 2010 I see. The templated implementation is a big improvement. If the
- bearophile (9/25) May 19 2010 I have not had problems with it, and people in D.learn seem to not compl...
- Bill Baxter (8/12) May 19 2010 It would also be chaos in D, since D lacks fine-grained control over nam...
Dear all, I once took a curious look at D in the past (circa 2004), and also read the DM newsgroups at the time that Stroustrup frequently posted here. Now, in 2010, I've been giving D 2.0 a second chance and I'm happy with it. Strings, dynamic arrays and hash tables couldn't be easier to use and the option of metaprogramming presents way more possibilities than C++. However, 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). 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 Thank you for taking the time to read my questions. Regards, F. Almeida
May 19 2010
F. Almeida <cpp.tutoring 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+=3D", 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(+=3D)", 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 macroThese character were chosen because not that many are available, and because they had no binary counterpart. A negate B makes no sense. 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 =C3=97, 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 =3D =C3=98; //empty set, same as "=3D void" int[] b =3D [1,2,3,4,5,6]; a =3D readInt(); if (a =E2=88=88 b) { // Element of - "in" float c =3D 2.00001; float d =3D readInt(); writefln(c =E2=89=88 =E2=8C=88d=E2=8C=89 ); // Approximately equal, c= eil myClass c =3D getInstance(); if (=E2=88=83c) { // c exists, i.e. "!is null" writefln(=E2=88=9A(c.foo)); } =E2=88=80element=E2=88=88b { // New foreach syntax! element *=3D =C2=BC; } } I hope we don't get to see this any time soon. -- = Simen
May 19 2010
I see. The templated implementation is a big improvement. If the intention was to prevent people to turn "+" into concatenation for example, I'm afraid anybody really keen on doing so would still overload opAdd. As a side note, C++0x is going to add a new suffix operator to C++. This operator would be useful in its own right. Are there any plans to add a new opSuffix!("s") operator in D?
May 19 2010
F. Almeida:Now, in 2010, I've been giving D 2.0 a second chance and I'm happy with it. Strings, dynamic arrays and hash tables couldn't be easier to use and the option of metaprogramming presents way more possibilities than C++.And there's a bit of possibility still to have AST macros in D3 (but recently they have got less probable).This can be confusing for people learning the language, especially if it's a first or second programming language.I have not had problems with it, and people in D.learn seem to not complain about it. Currently there are far worse problems in D2 syntax.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 macrois now used for properties (currently there is the property). a different semantics.If the intention was to prevent people to turn "+" into concatenation for example, I'm afraid anybody really keen on doing so would still overload opAdd.There was opCat plus language conventions. If programmers ignore them both, then they are stupid programmers. A language can't be designed to avoid really stupid errors like that, it's a wasted energy.As a side note, C++0x is going to add a new suffix operator to C++. This operator would be useful in its own right. Are there any plans to add a new opSuffix!("s") operator in D?Quite probably it will not become part of D, I think Andrei doesn't like that. D has Foo!"xxx"(...) syntax. Bye, bearophile
May 19 2010
On Wed, May 19, 2010 at 3:55 AM, bearophile <bearophileHUGS lycos.com> wrote:It would also be chaos in D, since D lacks fine-grained control over namespaces. D's module==namespace model means that every module has to be designed with the idea that every publicly visible entity is likely to end up in the global namespace. That doesn't really play together nicely with the notion of defining a bunch of what are essentially single-letter functions. --bbAs a side note, C++0x is going to add a new suffix operator to C++. This operator would be useful in its own right. Are there any plans to add a new opSuffix!("s") operator in D?Quite probably it will not become part of D, I think Andrei doesn't like that. D has Foo!"xxx"(...) syntax.
May 19 2010