[Issue 2934] "".dup does not return empty string

[d-bugmail at puremagic.com]

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


qian.xu at funkwerk-itk.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|INVALID                     |




------- Comment #3 from qian.xu at funkwerk-itk.com  2009-05-05 02:46 -------
> 2. String literals have a null character implicitly appended to them by the
> compiler.  This is done to ease calling c functions.  So a string literal's
> pointer cannot be null, since it has to point to a static zero byte.

I am fully agree with you. But before using ".dup" a string variable has
triple-state (null, empty or not empty). After adding a ".dup" to an empty
string, it might be reduced to two. This will break existing code, if defensive
copies of strings are made. 

An example is as follows:

  class test {
    private char[] val;
    char[] getVal() {
      return val.dup; // make a defensive copy to avoid unexpected change from
outside
    }
    void setVal(char[] val) {
      this.val = val.dup;
    }
  }

  myTestObj.setVal("");
  char[] s = myTestObj.getVal;
  if (s is null) {
    // do task 1
  }
  else if (s == "") {
    // do task 2
  }
  else {
    // do task 3
  }

In this case, task 2 is expected to be performed. However task 1 will be
performed. 


> Regardless of it is identified specifically in the spec or not, it is not
> a bug, as the alternative would be to allocate blocks for 0-sized arrays.

Did you mean, that this is a feature request? I would like to regard the
inconsistency of the dup-effect as a defect.


--