
<html><body bgcolor="#FFFFFF"><div><span class="Apple-style-span" style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.296875); -webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469); ">On Feb 6, 2011, at 6:58 PM, Jonathan M Davis <<a href="mailto:jmdavisProg@gmx.com">jmdavisProg@gmx.com</a>> wrote:</span></div><blockquote type="cite"><div><span></span><br><span>You really shouldn't be compiling with ddoc enabled unless you're building the </span><br><span>documentation. There are just too many cases where you need separate </span><br><span>declarations for ddoc - often because of differences between OSes. There are </span><br><span>cases where the ddoc version is different _on purpose_. In the case of </span><br><span>std.file.DirEntry.isDir, it's const on Windows because it can be. But because it </span><br><span>can't be on Linux, the ddoc version doesn't list it that way. Now, maybe it's on </span><br><span>negligble benefit to have isDir const on Windows given that it can't be on Linux, </span><br><span>but there are definitely cases where ddoc is forced to be different from a </span><br><span>particular OS' version of a declaration, simply because that declaration is </span><br><span>different on different systems.</span><br><span></span><br><span>Do _not_ expect your code to work if you compile with ddoc enabled.</span><font class="Apple-style-span" color="#005001"><font class="Apple-style-span" color="#0023A3"><br></font></font></div></blockquote><br><div>Such requirements feel like a failure of design. Are there any lessons learned from these kinds of problems? I'm sure Walter did not intend separate ddoc versions.</div></body></html>