diff -uNr dmd-0.127/dmd/html/d/changelog.html dmd-0.128/dmd/html/d/changelog.html
--- dmd-0.127/dmd/html/d/changelog.html 2005-06-16 21:54:14.000000000 +0200
+++ dmd-0.128/dmd/html/d/changelog.html 2005-07-10 23:32:10.000000000 +0200
@@ -37,7 +37,7 @@
| D
-Last update Thu Jun 16 2005
+Last update Sun Jul 10 2005
@@ -45,6 +45,7 @@
+
+
+Jul 10, 2005
+
+
+
New/Changed Features
+
+
+Bugs Fixed
+
+
+
What's New for
D 0.127
diff -uNr dmd-0.127/dmd/html/d/declaration.html dmd-0.128/dmd/html/d/declaration.html
--- dmd-0.127/dmd/html/d/declaration.html 2005-06-01 14:50:06.000000000 +0200
+++ dmd-0.128/dmd/html/d/declaration.html 2005-06-25 10:55:52.000000000 +0200
@@ -37,7 +37,7 @@
| D
-Last update Wed Jun 01 2005
+Last update Sat Jun 25 2005
Declarations
@@ -407,9 +407,9 @@
typeof(i) j; // j is of type int
typeof(3 + 6.0) x; // x is of type double
typeof(1)* p; // p is of type pointer to int
- int[typeof[p]] a; // a is of type int[int*]
+ int[typeof(p)] a; // a is of type int[int*]
- printf("%d\n", typeof('c').size); // prints 1
+ printf("%d\n", typeof('c').sizeof); // prints 1
double c = cast(typeof(1.0))j; // cast j to double
}
diff -uNr dmd-0.127/dmd/html/d/intro.html dmd-0.128/dmd/html/d/intro.html
--- dmd-0.127/dmd/html/d/intro.html 2005-05-22 10:46:58.000000000 +0200
+++ dmd-0.128/dmd/html/d/intro.html 2005-06-18 13:39:00.000000000 +0200
@@ -37,12 +37,10 @@
"Great, just what I need.. another D in programming." -- Segfault
This is the reference document for the D programming language.
- D was conceived in December 1999 by myself as a reengineering of C and C++,
+ D was conceived in December 1999 by Walter Bright as a reengineering of C and C++,
and has grown and evolved with helpful
- suggestions and critiques by my friends and colleagues.
- I've been told the usual, that there's no chance for a new programming
- language, that who do I think I am designing a language, etc. Take a
- look at the document and decide for yourself!
+ suggestions and critiques by friends and colleagues.
+
Check out the quick comparison
of D with C, C++, C# and Java.
@@ -59,7 +57,7 @@
Download the current version
- of the compiler for Win32 and x86 Linux and try it out!
+ of the compiler for Win32 and x86 Linux and try it out.
David Friedman has integrated the
D frontend with GCC.
@@ -78,7 +76,7 @@
"D Language Perfect Guide"
- For SDWest 2004 I gave a
+
Walter's SDWest 2004
presentation on D.
@@ -91,8 +89,6 @@
rights with a copyright or patent notice in any posted or emailed
feedback sent to Digital Mars.
- -Walter
-
Feedback and Comments
diff -uNr dmd-0.127/dmd/html/d/rationale.html dmd-0.128/dmd/html/d/rationale.html
--- dmd-0.127/dmd/html/d/rationale.html 1970-01-01 01:00:00.000000000 +0100
+++ dmd-0.128/dmd/html/d/rationale.html 2005-06-25 01:42:16.000000000 +0200
@@ -0,0 +1,296 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Digital Mars - The D Programming Language - Rationale
+
+
+
+
+
+
+Home
+| Search
+| D
+
+
+Last update Sat Jun 25 2005
+
+
+Rationale
+
+ Questions about the reasons for various design decisions for
+ D often come up. This addresses many of them.
+
+Operator Overloading
+
+Why 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?
+
+
+ - Operator overloading can only be done with an argument
+ as an object, so they logically belong as member functions
+ of that object. That does leave the case of what to do
+ when the operands are objects of different types:
+
+
+
+
+
+ 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) { }
+ }
+ |
+
+
- Operator overloads usually need access to private members
+ of a class, and making them global breaks the object oriented
+ encapsulation of a class.
+
+
+ - (2) can be addressed by operator overloads automatically gaining
+ "friend" access, but such unusual behavior is at odds with D
+ being simple.
+
+
+
+
+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.
+
+Properties
+
+Why 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::infinity
+?
+
+ 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:
+
+
+ - Building it in to the core language means the core language knows
+ what a floating point infinity is. Being layered in templates, typedefs,
+ casts, const bit patterns, etc., it doesn't know what it is, and is
+ unlikely to give sensible error messages if misused.
+
+
+ - A side effect of (1) is it is unlikely to be able to use it
+ effectively in constant folding and other optimizations.
+
+
+ - Instantiating templates, loading #include files, etc., all costs
+ compile time and memory.
+
+
+ - The worst, though, is the lengths gone to just to get at infinity,
+ implying "the language and compiler don't know anything about IEEE 754
+ floating point - so it cannot be relied on." And in fact
+ many otherwise excellent C++ compilers
+ do not handle NaN's correctly in floating point comparisons.
+ (Digital Mars C++ does do it correctly.)
+ C++98 doesn't say anything about NaN or Infinity handling in expressions
+ or library functions. So it must be assumed it doesn't work.
+
+
+
+
+ To sum up, there's a lot more to supporting NaNs and infinities than
+ having a template that returns a bit pattern. It has to be built in to
+ the compiler's core logic, and it has to permeate all the library code
+ that deals with floating point. And it has to be in the Standard.
+
+ To illustrate, if either op1 or op2 or both are
+ NaN, then:
+
+ does not yield the same result as:
+
+ if the NaNs are done correctly.
+
+
Why use static if(0) rather than if (0)?
+
+ Some limitations are:
+
+
+ - if (0) introduces a new scope, static if(...) does not. Why does this
+ matter? It matters if one wants to conditionally declare a new variable:
+
+
+
+
+ static if (...) int x; else long x;
+ x = 3;
+ |
+
+ whereas:
+
+
+
+
+ if (...) int x; else long x;
+ x = 3; // error, x is not defined
+ |
+
+
- False static if conditionals don't have to semantically work. For
+ example, it may depend on a conditionally compiled declaration somewhere
+ else:
+
+
+
+
+ static if (...) int x;
+ int test()
+ {
+ static if (...) return x;
+ else return 0;
+ }
+ |
+
+
- Static if's can appear where only declarations are allowed:
+
+
+
+
+ class Foo
+ {
+ static if (...)
+ int x;
+ }
+ |
+
+
- Static if's can declare new type aliases:
+
+
+
+
+ static if (0 || is(int T)) T x;
+ |
+
+
+
+Feedback and Comments
+
+ Add feedback and comments regarding this
+ page.
+
+
+Copyright © 1999-2005 by Digital Mars, All Rights Reserved
+
+
+
+
+
+
+
+
+
+
diff -uNr dmd-0.127/dmd/html/d/std_stream.html dmd-0.128/dmd/html/d/std_stream.html
--- dmd-0.127/dmd/html/d/std_stream.html 2005-06-03 18:29:28.000000000 +0200
+++ dmd-0.128/dmd/html/d/std_stream.html 2005-07-10 12:59:32.000000000 +0200
@@ -1,4 +1,5 @@
+