It's hard to argue whether something is or isn't bug prone and how severe the
bugs could be. An experienced programmer knows all the gotchas so he or she
will never introduce such bugs. A more bug-prone person will be afraid to speak
up in public so as not to appear stupid or be bullied away. It's only when the
language goes into production that the problems surface. Then an experienced
programmer becomes part of a group or not so experienced programmers and he or
she starts seeing how much the rests of the team is prone to certain bugs and
how hard it is to prevent or even detect them. That's why the best languages
attempt to turn as many errors as possible into hard bugs.
Non-deterministic behavior is a major source of soft bugs. A buggy program
might work correctly 99% of the time, introduce minor errors 0.9% of the time,
and in 0.1% of the time lead to a disaster.
I will try to come up with some scenarios that would qualify for the "100
Gotchas with D arrays" to provide more food for though. Consider these little
language puzzles.
Imagine you're reviewing this code written by a relative newbee:
char[] quote(char[] word) {
word.length += 2;
word[length-1] = '"';
for(int i = word.length-2; i > 0; --i)
word[i] = word[i - 1];
word[0] = '"';
return word;
}
void storeFoos(char[] buffer, string pattern, Container c)
{
char[] res = find(buffer, pattern);
c.store(quote(res[0..pattern.len]);
}
Is this buggy? If so, how and when will the bug manifest itself?
Or another story. An enthusiastic programmer comes to you with a very clever
rewrite of a function. This is the original:
T[] duplicate(T)(T[] src) {
static if (is(T == invariant))
return src.idup;
else
return src.dup;
}
This is his improved version:
T[] duplicate(T)(T[] src) {
T tmp = src[$-1];
src.length -= 1;
src ~= tmp;
return src;
}
No need for static if! The extension is bound to re-allocate because of
stomping rules. Will this always work, or is there a gotcha?
