Comments on: D Gotchas

By: D update mitigates comparison gotcha

D update mitigates comparison gotcha — Tue, 11 Mar 2008 18:13:11 +0000

[...] I’ve written about in a previous post this could be a source of confusion for beginners, like myself. Someone who’s used to the [...]

By: jimsotonna

jimsotonna — Mon, 03 Mar 2008 06:04:46 +0000

jimsotonna…

jimsotonna dropped by…

By: HeavyGod

HeavyGod — Tue, 27 Nov 2007 08:56:50 +0000

Really good and really interesting post. I expect (and other readers maybe :)) new useful posts from you!
Good luck and successes in blogging!

By: Henning

Henning — Thu, 08 Nov 2007 14:17:34 +0000

Addition: You are right that similarity to C/C++ is also important for intuitivity. But maybe an optional flag that warns about such implicit conversions or something along those lines would be nice.

By: Henning

Henning — Thu, 08 Nov 2007 14:14:36 +0000

There are some other unintuitive things, such as

uint a;
int b;

a = 1;
b = -3;
writefln(a + b); // 4294967294

This may seem no problem at a first sight but when working for example with sdl where rectangle sizes are unsigned and positions are signed this produces not-too-easy trackable errors in my code regulary.

Even if I think of it at the time writing it, I find it ugly to having to cast around that much.

By: Hans-Eric

Hans-Eric — Thu, 08 Nov 2007 09:50:15 +0000

If D’s handling of conversions was opposite what C and C++ (and other languages) do it would confuse a lot of programmers.

I totally agree!

If you think this through I believe you’ll conclude that C, C++, and D are doing the right thing, and the alternative you propose is actually more confusing.

I don’t agree on this one. The result of a division between two integers is most likely not an integer, so why should that be the default?

By: Hans-Eric

Hans-Eric — Thu, 08 Nov 2007 09:34:14 +0000

I can’t imagine how bad the confusion would be if D didn’t have 3/2 == 1. For a language that keeps such syntactic closeness to C, it would be a nightmare.

I agree. This is of course the reason.

By: Greg Jorgensen

Greg Jorgensen — Wed, 07 Nov 2007 18:49:57 +0000

The Premature Conversion gotcha is a particularly nasty one. It compiles and runs, which means only testing can reveal this bug.

Presumably D is aimed at programmers who know C and C++. The premature conversion you describe is not a bug, it’s how C and C++ already work. The expression itself has a type regardless of what it is ultimately assigned to. The type of dividing one integer by another is an integer. Assign that value to a real causes the type conversion.

In C:
double x;

x = 5 / 2; printf("%f", x);

Outputs 2.000000.

If D’s handling of conversions was opposite what C and C++ (and other languages) do it would confuse a lot of programmers.

If you think this through I believe you’ll conclude that C, C++, and D are doing the right thing, and the alternative you propose is actually more confusing.

By: sapphirecat

sapphirecat — Wed, 07 Nov 2007 16:52:46 +0000

Python won’t stay that way much longer. C-style integer division is a misfeature which will be removed in 3.0. You can also get it in Python 2.5:

from __future__ import division
a = 5/2 # 2.5
b = 5//2 # 2 (old behavior with new operator)

By: Brendan Kohler

Brendan Kohler — Wed, 07 Nov 2007 16:42:20 +0000

>What’s interesting is that both of these features are from Visual
> Basic, and the syntax and behavior is almost identical.

They were in VB, not from it. Python, which had its first release a couple months prior to the release of VB in 1991, had the “is” operator.

No, the “is” operator is from Delphi (Object Pascal).

All the rest of the stuff is taken directly from C.

I can’t imagine how bad the confusion would be if D didn’t have 3/2 == 1. For a language that keeps such syntactic closeness to C, it would be a nightmare.

No, even python never actually moved to having the default be “true division”. The great thing about integer division is how much more accurate it is than floating point, simply because you can keep exact answers by using the modulus…something floating point cannot do.