[Issue 4733] Possible bugs caused by dynamic arrays in boolean evaluation context

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=4733



--- Comment #2 from bearophile_hugs at eml.cc 2013-03-25 15:59:36 PDT ---
I have created a thread about this issue in the main D newsgroup:

http://forum.dlang.org/thread/bwgnbflygowctlisistg@forum.dlang.org

It was well received by almost every one. But people are split between just
forbidding "if(dyn_arr)" and turning it into an equivalent of
"if(dyn_arr.length)". Both proposals have advantages and disadvantages.

Both are a little breaking change, but turning something into an error allows
you to find it quickly in most cases inside D code. (But D also has the
compiles __trait, that does not give an error, it just silently returns false
instead of true).

On the other hand the behaviour change is not meant to happen all at once. It
has to be a warning, then deprecation and then a change, along months and three
DMD versions. So there is time to fix old D code. And even if the old D code
doesn't get changed, I think it's uncommon for code to rely on dynamic array to
be actually (null,null) instead of being of zero length. So the total amount of
breakage even for a semantic change is probably small. Considering the presence
of the compiles __trait, the idea of the small behaviour change is not so bad.

In both cases the change path will start at the same way: warning, deprecation,
and then an error or a behavour change). So for now I am asking for a warning
for code like "if(dyn_arr)".

Note that the syntax "if(dyn_arr !is null)" is still allowed.

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

A related issue is what to do with associative arrays:


void main() {
    bool[int] aa;
    assert(!aa);
    aa = [1: true];
    assert(aa);
    aa.remove(1);
    assert(aa);
    assert(!aa.length);
}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------