What's weird about this? Processors raise
an exception when you ask them to divide by
zero.
Perhaps "Floating point exception" is a weird
message to give, but that's something the operating
system does; it is the default signal handler's
message.
I guess it is also a little weird that it didn't
say "test9.d(2): Error: divide by 0".. the to!uint
seems to trick dmd into not realizing what you are
saying. It catches the literal 1 % 0.

What's weird about this? Processors raise
an exception when you ask them to divide by
zero.
Perhaps "Floating point exception" is a weird
message to give, but that's something the operating
system does; it is the default signal handler's
message.

That is the problem. No floating point operation is involved here. And
if you replace to!uint("1") by just plain old 1, you don't get the same
message, which is very inconsistent, and counterintuitive.

I did, it doesn't address why in one case we have a floating
point error, and in the other a divide error

If you use literals, the compiler catches it at compile
time. "Error: divide by zero" happens when you run the
compiler.
If not, the operating system catches it at runtime.
"Floating point exception" happens when you run the
program.
There's nothing inconsistent about this; it is just
the difference between a compile time error and a
run time error.

I did, it doesn't address why in one case we have a floating point
error, and in the other a divide error

If you use literals, the compiler catches it at compile
time. "Error: divide by zero" happens when you run the
compiler.
If not, the operating system catches it at runtime.
"Floating point exception" happens when you run the
program.
There's nothing inconsistent about this; it is just
the difference between a compile time error and a
run time error.

The 0 is known at comile time. You should get the error at compile time.

I did, it doesn't address why in one case we have a floating point
error, and in the other a divide error

If you use literals, the compiler catches it at compile
time. "Error: divide by zero" happens when you run the
compiler.
If not, the operating system catches it at runtime.
"Floating point exception" happens when you run the
program.
There's nothing inconsistent about this; it is just
the difference between a compile time error and a
run time error.

The 0 is known at comile time. You should get the error at compile tim=

e.
The divide by zero is an error during constfolding not a specific compil=
er =
check.

I bet he did, but settled to responding to the part that was explicitly
marked as being 'the problem'.

You'll find 2 problems, not one.
Problem one is the floating point reference, which is a problem when no
floating point is involved. This is the counterintuitive part.
Problem two is the inconsistency of behavior. Sometime a divide error is
triggered and some other a floating point error. This is the
inconsistent part.

I bet he did, but settled to responding to the part that was explicitly
marked as being 'the problem'.

You'll find 2 problems, not one.
Problem one is the floating point reference, which is a problem when no
floating point is involved. This is the counterintuitive part.
Problem two is the inconsistency of behavior. Sometime a divide error is
triggered and some other a floating point error. This is the inconsisten=

Ok, so it turns out I wasn't completely wrong.
While the C standards states that SIGFPE will never be thrown for uint
types, D presumably makes no such guarantee. Also, the example there
uses `int`s and the compiler warns about a division by zero, then
running it causes a floating point error.
So other than the fact that you are using `uint`s rather than `int`s
the behaviour is identical to that of C.
--
James Miller