Thread overview | |||||||
---|---|---|---|---|---|---|---|
|
May 19, 2010 Questions about syntax decisions | ||||
---|---|---|---|---|
| ||||
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 preprocessor means that "#" is available, for example. Thank you for taking the time to read my questions. Regards, F. Almeida |
May 19, 2010 Re: Questions about syntax decisions | ||||
---|---|---|---|---|
| ||||
Posted in reply to F. Almeida | 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+=", 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 |
May 19, 2010 Re: Questions about syntax decisions | ||||
---|---|---|---|---|
| ||||
Posted in reply to Simen kjaeraas | 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 Re: Questions about syntax decisions | ||||
---|---|---|---|---|
| ||||
Posted in reply to F. Almeida | 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 macro > preprocessor means that "#" is available, for example. @ is now used for properties (currently there is the @property). # is used only minimally. D tries to not add syntax that is valid C syntax with 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 Re: Questions about syntax decisions | ||||
---|---|---|---|---|
| ||||
Posted in reply to bearophile | On Wed, May 19, 2010 at 3:55 AM, bearophile <bearophileHUGS@lycos.com> wrote:
>
>> 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.
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.
--bb
|
Copyright © 1999-2021 by the D Language Foundation