· Overview · D for Win32 · Win32 DLLs in D · C .h to D Modules · FAQ · Style Guide · Example: wc · Future · D Change Log · Tech Tips · Rationale · Exception Safety · Templates Revisited · Warnings · Glossary · Acknowledgements Tools · DMD D Compiler · GDC D Compiler · Linker · Profiler · Code Coverage · DMD Script Shell Community · News · Forum · Announcements · Learn · D links Archives · digitalmars.D · digitalmars.D.dtl · digitalmars.D.announce · digitalmars.D.dwt · digitalmars.D.learn · digitalmars.D.bugs · D.gnu · Old D |
RationaleQuestions about the reasons for various design decisions for D often come up. This addresses many of them.Operator OverloadingWhy not name them operator+(), operator*(), etc.?This is the way C++ does it, and it is appealing to be able to refer to overloading '+' with 'operator+'. The trouble is things don't quite fit. For example, there are the comparison operators <, <=, >, and >=. In C++, all four must be overloaded to get complete coverage. In D, only a cmp() function must be defined, and the comparison operations are derived from that by semantic analysis.Overloading operator/() also provides no symmetric way, as a member function, to overload the reverse operation. For example, class A { int operator/(int i); // overloads (a+i) static operator/(int i, A a) // overloads (i+a) }The second overload does the reverse overload, but it cannot be virtual, and so has a confusing asymmetry with the first overload. Why not allow globally defined operator overload functions?
class A { } class B { } int add(class A, class B);Should add() be in class A or B? The obvious stylistic solution would be to put it in the class of the first operand, class A { int add(class B) { } } Why not allow user definable operators?These can be very useful for attaching new infix operations to various unicode symbols. The trouble is that in D, the tokens are supposed to be completely independent of the semantic analysis. User definable operators would break that.Why not allow user definable operator precedence?The trouble is this affects the syntax analysis, and the syntax analysis is supposed to be completely independent of the semantic analysis in D.Why not use operator names like __add__ and __div__ instead of add, div, etc.?__ keywords should indicate a proprietary language extension, not a basic part of the language.Why not have binary operator overloads be static members, so both arguments are specified, and there no longer is any issue with the reverse operations?This means that the operator overload cannot be virtual, and so likely would be implemented as a shell around another virtual function to do the real work. This will wind up looking like an ugly hack. Secondly, the cmp() function is already an operator overload in Object, it needs to be virtual for several reasons, and making it asymmetric with the way other operator overloads are done is unnecessary confusion.PropertiesWhy does D have properties like T.infinity in the core language to give the
infinity of a floating point type, rather than doing it in a library like C++:
std::numeric_limits
Let's rephrase that as "if there's a way to express it in the existing
language, why build it in to the core language?"
In regards to T.infinity:
|