This is the correct behavior.  For whatever reason x86 CPUs create a NaN with the sign bit set to 1 when they get a 0.0 / 0.0.  writeln() just displays the sign bit of the NaN because it gives the programmer more information about how the NaN was triggered.  The following code demonstrates that the sign bit is set to 1.

import std.stdio;

void main() {
    double myNan = 0.0 / 0.0;
    ulong asInt = *(cast(ulong*) &myNan); 
    writeln(asInt & (1UL << 63));  // Prints some huge number.
}

OK. Thank you for your answer. I will not reopen this bug because it's a minor thing, but I don't like it because:

From a purely ideal point of view, a NaN isn't a number, so it can't be positive or negative, it's "undefined", that is not negative.

In 0.0/0.0 both values are positive, so if you extend the semantics of division between two positive real numbers, the result can't be negative.

And because no other language I know of (including D printf) seems to print a "negative nan" in that situation:

-------------------

In D (2.048) if you run this program:

import std.stdio;
void main() {
  printf("%f\n", 0.0 / 0.0);
}


It prints "nan".

-------------------

This D1 program (dmd 1.026):

import std.stdio;
void main() {
  writefln("%f", 0.0 / 0.0);
}


Prints "nan".

-------------------

In C if you run this program:

#include "stdio.h"
int main() {
  printf("%f\n", 0.0 / 0.0);
  return 0;
}

It prints "nan".

-------------------

In Scala language, this program:

import java.io.{BufferedReader, InputStreamReader}
 
object Main {
  def main(args: Array[String]) {
      System.out.println(0.0 / 0.0);
  }
}

Prints "NaN".

-------------------

In Haskell (that is a quite mathematical-oriented language), this program:

main = do
   putStr  (show (0.0 / 0.0))


Prints "NaN".

-------------------

In F#, this program:

open System
do
    System.Console.Write(0.0 / 0.0)

Prints "NaN".

-------------------