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

[Derek Parnell]

On Mon, 4 May 2009 17:44:56 +0000 (UTC), d-bugmail at puremagic.com wrote:

> http://d.puremagic.com/issues/show_bug.cgi?id=2934
> 
> schveiguy at yahoo.com changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>              Status|NEW                         |RESOLVED
>          Resolution|                            |INVALID
> 
> ------- Comment #2 from schveiguy at yahoo.com  2009-05-04 12:45 -------
> From posts in the newsgroup, I've determined that this bug is invalid:
> 
> 1. Duplicating an empty array should always return a null array.  Otherwise,
> you'd have to allocate space to store 0 data bytes in order for the result to
> be non-null.
> 
> 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.
> 
> The spec identifies specifically item 2 here:
> http://www.digitalmars.com/d/1.0/arrays.html#strings
> 
> see the section describing "C's printf and Strings"
> 
> I could not find a reference for item 1, but I remember reading something about
> it.  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.

Huh??? Duplicating something should give one a duplicate.

I do not think that this is an invalid bug.

Ok, so duplicating an empty array causes memory to be allocated - so what!
I asked for a duplicate so give me a duplicate, please.

To me, the "no surprise" path is simple. Duplicating an empty array should
return an empty array. Duplicating a null array should return a null array.

Is that not intuitive?

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell