diff -uNr dmd-0.115/dmd/html/d/changelog.html dmd-0.116/dmd/html/d/changelog.html --- dmd-0.115/dmd/html/d/changelog.html 2005-02-28 20:02:26.000000000 +0100 +++ dmd-0.116/dmd/html/d/changelog.html 2005-03-07 14:58:10.000000000 +0100 @@ -24,6 +24,7 @@
+

+ What's New for + D 0.116 +

+ +Mar 7, 2005 +

+ +

New/Changed Features

+ + +

Bugs Fixed

+ + +

What's New for D 0.115 @@ -252,7 +297,7 @@ The std.stream changes are: diff -uNr dmd-0.115/dmd/html/d/dcompiler.html dmd-0.116/dmd/html/d/dcompiler.html --- dmd-0.115/dmd/html/d/dcompiler.html 2005-02-13 11:58:00.000000000 +0100 +++ dmd-0.116/dmd/html/d/dcompiler.html 2005-03-07 16:17:34.000000000 +0100 @@ -1,6 +1,6 @@ + + nbsp 160   + iexcl 161 ¡ + cent 162 ¢ + pound 163 £ + curren 164 ¤ + yen 165 ¥ + brvbar 166 ¦ + sect 167 § + uml 168 ¨ + copy 169 © + ordf 170 ª + laquo 171 « + not 172 ¬ + shy 173 ­ + reg 174 ® + macr 175 ¯ + deg 176 ° + plusmn 177 ± + sup2 178 ² + sup3 179 ³ + acute 180 ´ + micro 181 µ + para 182 ¶ + middot 183 · + cedil 184 ¸ + sup1 185 ¹ + ordm 186 º + raquo 187 » + frac14 188 ¼ + frac12 189 ½ + frac34 190 ¾ + iquest 191 ¿ + Agrave 192 À + Aacute 193 Á + Acirc 194 Â + Atilde 195 Ã + Auml 196 Ä + Aring 197 Å + AElig 198 Æ + Ccedil 199 Ç + Egrave 200 È + Eacute 201 É + Ecirc 202 Ê + Euml 203 Ë + Igrave 204 Ì + Iacute 205 Í + Icirc 206 Î + Iuml 207 Ï + ETH 208 Ð + Ntilde 209 Ñ + Ograve 210 Ò + Oacute 211 Ó + Ocirc 212 Ô + Otilde 213 Õ + Ouml 214 Ö + times 215 × + Oslash 216 Ø + Ugrave 217 Ù + Uacute 218 Ú + Ucirc 219 Û + Uuml 220 Ü + Yacute 221 Ý + THORN 222 Þ + szlig 223 ß + agrave 224 à + aacute 225 á + acirc 226 â + atilde 227 ã + auml 228 ä + aring 229 å + aelig 230 æ + ccedil 231 ç + egrave 232 è + eacute 233 é + ecirc 234 ê + euml 235 ë + igrave 236 ì + iacute 237 í + icirc 238 î + iuml 239 ï + eth 240 ð + ntilde 241 ñ + ograve 242 ò + oacute 243 ó + ocirc 244 ô + otilde 245 õ + ouml 246 ö + divide 247 ÷ + oslash 248 ø + ugrave 249 ù + uacute 250 ú + ucirc 251 û + uuml 252 ü + yacute 253 ý + thorn 254 þ + yuml 255 ÿ + + + + fnof 402 ƒ + Alpha 913 Α + Beta 914 Β + Gamma 915 Γ + Delta 916 Δ + Epsilon 917 Ε + Zeta 918 Ζ + Eta 919 Η + Theta 920 Θ + Iota 921 Ι + Kappa 922 Κ + Lambda 923 Λ + Mu 924 Μ + Nu 925 Ν + Xi 926 Ξ + Omicron 927 Ο + Pi 928 Π + Rho 929 Ρ + Sigma 931 Σ + Tau 932 Τ + Upsilon 933 Υ + Phi 934 Φ + Chi 935 Χ + Psi 936 Ψ + Omega 937 Ω + alpha 945 α + beta 946 β + gamma 947 γ + delta 948 δ + epsilon 949 ε + zeta 950 ζ + eta 951 η + theta 952 θ + iota 953 ι + kappa 954 κ + lambda 955 λ + mu 956 μ + nu 957 ν + xi 958 ξ + omicron 959 ο + pi 960 π + rho 961 ρ + sigmaf 962 ς + sigma 963 σ + tau 964 τ + upsilon 965 υ + phi 966 φ + chi 967 χ + psi 968 ψ + omega 969 ω + thetasym 977 ϑ + upsih 978 ϒ + piv 982 ϖ + bull 8226 • + hellip 8230 … + prime 8242 ′ + Prime 8243 ″ + oline 8254 ‾ + frasl 8260 ⁄ + weierp 8472 ℘ + image 8465 ℑ + real 8476 ℜ + trade 8482 ™ + alefsym 8501 ℵ + larr 8592 ← + uarr 8593 ↑ + rarr 8594 → + darr 8595 ↓ + harr 8596 ↔ + crarr 8629 ↵ + lArr 8656 ⇐ + uArr 8657 ⇑ + rArr 8658 ⇒ + dArr 8659 ⇓ + hArr 8660 ⇔ + forall 8704 ∀ + part 8706 ∂ + exist 8707 ∃ + empty 8709 ∅ + nabla 8711 ∇ + isin 8712 ∈ + notin 8713 ∉ + ni 8715 ∋ + prod 8719 ∏ + sum 8721 ∑ + minus 8722 − + lowast 8727 ∗ + radic 8730 √ + prop 8733 ∝ + infin 8734 ∞ + ang 8736 ∠ + and 8743 ∧ + or 8744 ∨ + cap 8745 ∩ + cup 8746 ∪ + int 8747 ∫ + there4 8756 ∴ + sim 8764 ∼ + cong 8773 ≅ + asymp 8776 ≈ + ne 8800 ≠ + equiv 8801 ≡ + le 8804 ≤ + ge 8805 ≥ + sub 8834 ⊂ + sup 8835 ⊃ + nsub 8836 ⊄ + sube 8838 ⊆ + supe 8839 ⊇ + oplus 8853 ⊕ + otimes 8855 ⊗ + perp 8869 ⊥ + sdot 8901 ⋅ + lceil 8968 ⌈ + rceil 8969 ⌉ + lfloor 8970 ⌊ + rfloor 8971 ⌋ + lang 9001 ⟨ + rang 9002 ⟩ + loz 9674 ◊ + spades 9824 ♠ + clubs 9827 ♣ + hearts 9829 ♥ + diams 9830 ♦ + + + + +

Feedback and Comments

+ + Add feedback and comments regarding this + page. + +
Copyright (c) 2005 by Digital Mars, All Rights Reserved

+ + + + diff -uNr dmd-0.115/dmd/html/d/intro.html dmd-0.116/dmd/html/d/intro.html --- dmd-0.115/dmd/html/d/intro.html 2004-12-14 10:36:34.000000000 +0100 +++ dmd-0.116/dmd/html/d/intro.html 2005-03-04 14:53:18.000000000 +0100 @@ -1,6 +1,6 @@ diff -uNr dmd-0.115/dmd/html/d/lex.html dmd-0.116/dmd/html/d/lex.html --- dmd-0.115/dmd/html/d/lex.html 2005-02-09 22:00:10.000000000 +0100 +++ dmd-0.116/dmd/html/d/lex.html 2005-03-07 09:36:26.000000000 +0100 @@ -10,7 +10,7 @@ [Search] [D] -
Last update Jan 19, 2004 +
Last update Mar 7, 2005

Lexical

@@ -44,7 +44,9 @@
  • lexical analysis
    The source file is divided up into a sequence of tokens. - Special tokens are processed and removed. + Special tokens are replaced with other tokens. + Special token sequences + are processed and removed.
  • syntax analysis
    @@ -196,7 +198,7 @@ 
     	a = /+ // +/ 1;		// parses as if 'a = 1;'
-	a = /+ "+/" +/ 1";	// parses as if 'a = " +/1";'
+	a = /+ "+/" +/ 1";	// parses as if 'a = " +/ 1";'
 	a = /+ /* +/ */ 3;	// parses as if 'a = */ 3;'
    @@ -334,7 +336,7 @@ EscapeSequence EndOfLine - EscapeSequence: + EscapeSequence: \' \" \? @@ -353,6 +355,7 @@ \ OctalDigit OctalDigit OctalDigit \u HexDigit HexDigit HexDigit HexDigit \U HexDigit HexDigit HexDigit HexDigit HexDigit HexDigit HexDigit HexDigit + \& NamedCharacterEntity ; HexString: x" HexStringChars " @@ -414,10 +417,11 @@ \x1A hex \u1234 wchar character \U00101234 dchar character + \® ® dchar character \r\n carriage return, line feed - Escape sequences not listed above are errors. + Undefined escape sequences are errors.

    Hex strings allow string literals to be created using hex data: @@ -807,7 +811,35 @@ with -

    Special Token Sequences

    +

    Special Tokens

    + + These tokens are replaced with other tokens according to the following + table: +

    + + + + + + + + +
    Special Token + Replaced with... +
    __FILE__ + string literal containing source file name +
    __LINE__ + integer literal of the current source line number +
    __DATE__ + string literal of the date of compilation "mmm dd yyyy" +
    __TIME__ + string literal of the time of compilation "hh:mm:ss" +
    __TIMESTAMP__ + string literal of the date and time of compilation "www mmm dd hh:mm:ss yyyy" +
    +

    + +

    Special Token Sequences

    Special token sequences are processed by the lexical analyzer, may appear between any other tokens, and do not affect the syntax @@ -850,7 +882,7 @@ target="_top" title="Wiki 4 D">feedback and comments regarding this page. -
    Copyright (c) 1999-2004 by Digital Mars, All Rights Reserved

    +

    Copyright © 1999-2005 by Digital Mars, All Rights Reserved

    diff -uNr dmd-0.115/dmd/html/d/overview.html dmd-0.116/dmd/html/d/overview.html --- dmd-0.115/dmd/html/d/overview.html 2004-10-19 01:37:50.000000000 +0200 +++ dmd-0.116/dmd/html/d/overview.html 2005-03-04 14:52:56.000000000 +0100 @@ -1,7 +1,7 @@ + +Digital Mars - Warnings + + + +www.digitalmars.com +[Home] +[Search] +[D] +
    Last update Mar 1, 2005 +

    + +

    Warnings

    + + Depending on one's point of view, warnings are either a symptom + of broken language design or a useful 'lint' like tool to analyze + code and look for potential trouble spots. + Most of the time, those trouble spots will be legitimate code + intended to be that way. More rarely, it may indicate an + unintentional error on the part of the programmer. +

    + + Warnings are not a defined part of the D Programming Language. + They exist at the discretion of the compiler vendor, and + will most likely vary from vendor to vendor. + All constructs for which an implementation may generate a warning + message are legal D code. +

    + + These are the warnings generated by the Digital Mars D compiler + when the -w switch is thrown. + Most have generated some spirited debate as to whether it should + be a warning, an error, and what the correct way to write D code + in these situations should be. Since no consensus emerged, + they appear as optional warnings, with alternatives on how to + write correct code. + +

    warning - implicit conversion of expression expr of type type to type can cause loss of data

    + + D follows the C and C++ rules regarding default integral promotion + in expressions. This is done for both compatibility reasons + and because modern CPUs are designed to execute such semantics + efficiently. These rules also include implicit narrowing rules, + where the result of such can be cast back into a smaller type, + perhaps losing significant bits in the process: + + 
    +	byte a,b,c;
+	...
+	a = b + c;
    + + The b and c are both promoted to type int using + the default integral promotion rules. The result of the add is then + also int. To be assigned to a, that int gets + implicitly converted to a byte. +

    + + Whether it is a bug or not in the program depends on if the values + for b and c can possibly cause an overflow, and + if that overflow matters or not to the algorithm. + The warning can be resolved by: + +

      +
    1. Inserting a cast: + 
      +	a = cast(byte)(b + c);
      + This eliminates the warning, but since casting is a blunt instrument + that bypasses type checking, this can mask another bug that could + be introduced if the types of a, b or c + change in the future, or if their types are set by a template + instantiation. (In generic code, the cast(byte) would + probably be cast(typeof(a))). + +
    2. Changing the type of a to int. + This is generally a better solution, but of course may not work + if it must be a smaller type, which leads us to: + +
    3. Doing a runtime check for overflow: + 
      +	byte a,b,c;
+	int tmp;
+	...
+	tmp = b + c;
+	assert(cast(byte)tmp == tmp);
+	a = cast(byte)tmp;
      + This ensures that no significant bits get lost. +
    + + Some proposed language solutions are: + +
      +
    1. Having the compiler automatically insert the equivalent of + the option 3 runtime check. + +
    2. Add a new construct, + implicit_cast(type)expression + that is a restricted form of the general cast, and will only + work where implicit casts would normally be allowed. + +
    3. Implement the implicit_cast as a template. + +
    + +

    warning - array 'length' hides other 'length' name in outer scope

    + + Inside the [ ] of an array indexing expression or slice, the + variable length gets defined and set to be the length + of that array. The scope of the length is from the opening + '[' to the closing ']'. +

    + + If length was declared as a variable name + in an outer scope, that version may have been intended for + use between the [ ]. For example: + + 

    +	char[10] a;
+	int length = 4;
+	...
+	return a[length - 1];	// returns a[9], not a[3]
    + + The warning can be resolved by: + +
      +
    1. Renaming the outer length to another name. + +
    2. Replacing the use of length within the [ ] + with a.length. + +
    3. If length is at global or class scope, and that was the + one intended to be used, use .length or this.length + to disambiguate. +
    + + Some proposed language solutions are: + +
      +
    1. Make the length a special symbol or a keyword instead + of an implicitly declared variable. +
    + +

    warning - no return at end of function

    + + Consider the following: + 
    +	int foo(int k, Collection c)
+	{
+	    foreach (int x; c)
+	    {
+		if (x == k)
+		    return x + 1;
+	    }
+	}
    + + and assume that the nature of the algorithm is that x will + always be found in c, so the foreach never falls + through the bottom of the code. + There is no return at the close of the function, because + that point is not reachable and any return statement would + be dead code. + This is perfectly legitimate code. + The D compiler, to help with ensuring the robustness of such + code, will ensure it is correct by automatically inserting + an assert(0); statement at the close of the function. + Then, if there's an error in the assumption that the foreach will + never fall through, it will be caught at runtime with + an obvious assertion failure, which is better than the code just + falling off the end causing erratic, arbitrary failures. +

    + + D's behavior on this, however, is not common to other languages, + and some programmers will be acutely uncomfortable with relying + on this, or they wish to see the error at compile time rather + than runtime. They wish to see something explicit expressed in the + source code that the foreach cannot fall through. + Hence the warning. +

    + + The warning can be resolved by: + +

      +
    1. Putting a return statement at the close of the function, + returning some arbitrary value (after all, it will never be + executed): + + 
      +	int foo(int k, Collection c)
+	{
+	    foreach (int x; c)
+	    {
+		if (x == k)
+		    return x + 1;
+	    }
+	    return 0;	// suppress warning about no return statement
+	}
      + + While doing this is surprisingly common, and happens when + the programmer is inexperienced or in a hurry, it is a + spectacularly bad solution. + The trouble happens when the foreach does fall through + due to a bug, then instead of the bug being detected, now + the function returns an unexpected value, which may cause other + problems or go undetected. + There's another issue with the maintenance programmer who + sees this, and upon analyzing the code's behavior, wonders why + there's a return statement that will never be executed. + (This can be resolved with comments, but comments are always + missing, out of date, or just plain wrong.) + Dead code is always a confusing problem to maintenance programming, + so deliberately inserting it is a bad idea. + +
    2. A better solution is to make explicit what the D language + does implicitly - put an assert there: + + 
      +	int foo(int k, Collection c)
+	{
+	    foreach (int x; c)
+	    {
+		if (x == k)
+		    return x + 1;
+	    }
+	    assert(0);
+	}
      + + Now, if the foreach does fall through, the error will be + detected. Furthermore, it is self-documenting. + +
    3. Another alternative is to do a throw with a custom + error class and a more user friendly message: + + 
      +	int foo(int k, Collection c)
+	{
+	    foreach (int x; c)
+	    {
+		if (x == k)
+		    return x + 1;
+	    }
+	    throw new MyErrorClass("fell off the end of foo()");
+	}
      + +
    + +

    warning - switch statement has no default

    + + Similar to the no return statement warning is the no default + in a switch warning. Consider: + + 
    +	switch (i)
+	{
+	    case 1: dothis(); break;
+	    case 2: dothat(); break;
+	}
    + + According to the D language semantics, this means the only possible + values for i are 1 and 2. Any other values represent a bug + in the program. To detect this bug, the compiler implements the + switch as if it were written: + + 
    +	switch (i)
+	{
+	    case 1: dothis(); break;
+	    case 2: dothat(); break;
+	    default: throw new SwitchError();
+	}
    + + This is quite different from C and C++ behavior, which is as if + the switch were written: + + 
    +	switch (i)
+	{
+	    case 1: dothis(); break;
+	    case 2: dothat(); break;
+	    default: break;
+	}
    + + The potential for bugs with that is high, as it is a common error + to accidentally omit a case, or to add a new value in one part of + the program and overlook adding a case for it in another part. + Although D will catch this error at runtime, some prefer at least + a warning so such errors can be caught at compile time. +

    + + The warning can be resolved by: + +

      +
    1. Inserting an explict default of the form: + + 
      +	switch (i)
+	{
+	    case 1: dothis(); break;
+	    case 2: dothat(); break;
+	    default: assert(0);
+	}
      + +
    2. As in the missing return, a default with a throw of a custom + error class can be used. +
    + +

    warning - statement is not reachable

    + + Consider the following code: + + 
    +	int foo(int i)
+	{
+	    return i;
+	    return i + 1;
+	}
    + + The second return statement is not reachable, i.e. it is dead + code. While dead code is poor style in released code, it can + legitimately + happen a lot when rapidly trying to isolate down a bug or experiment + with different bits of code. + + The warning can be resolved by: + +
      +
    1. Commenting out the dead code with /+ ... +/ comments: + 
      +	int foo(int i)
+	{
+	    return i;
+	    /+
+		return i + 1;
+	     +/
+	}
      + +
    2. Putting the dead code inside a version(none) conditional: + 
      +	int foo(int i)
+	{
+	    return i;
+	    version (none)
+	    {
+		return i + 1;
+	    }
+	}
      + +
    3. Only compile with warnings enabled when doing release builds. +
    + +

    Feedback and Comments for this Page

    + + Add feedback and comments regarding this + page. + +
    Copyright (c) 2005 by Digital Mars, All Rights Reserved

    + + + +