On Thursday 04 August 2011 00:27:12 Mike Parker wrote:
> On 8/3/2011 11:23 PM, simendsjo wrote:
> > On 03.08.2011 15:49, bearophile wrote:
> >> simendsjo:
> >>> void main() {
> >>> assert(is(typeof("") == typeof("".idup))); // both is
> >>> immutable(char)[]
> >>>
> >>> assert("" !is null);
> >>> assert("".idup !is null); // fails - s is null. Why?
> >>> }
> >>
> >> I think someone has even suggested to statically forbid "is null" on
> >> strings :-)
> >>
> >> Bye,
> >> bearophile
> >
> > How should I test for null if not with "is null"? There is a difference
> > between null and empty, and avoiding this is not necessarily easy or
> > even wanted.
> > I couldn't find anything in the specification stating this difference.
> > So... Is it a bug?
>
> This is apparently a bug. Somehow, the idup is clobbering the pointer.
> You can see it more clearly here:
>
> void main()
> {
> assert("".ptr);
>
> auto s = "".idup;
> assert(s.ptr); // boom!
> }
I don't know if it's a bug or not. The string _was_ duped. assert(s == "")
passes. So, as far as equality goes, they're equal, and they don't point to
the same memory. Now, you'd think that the new string would be just empty
rather than null, but whether it's a bug or not depends exactly on what dup
and idup are supposed to do with regards to null. It's probably just a side
effect of how dup and idup are implemented rather than it being planned one way
or the other. I don't know if it matters or not though. In general, I don't
like the conflation of null and empty, but is this particular case, you _do_
get a string which is equal to the original and which doesn't point to the
same memory. So, I don't know whether this should be considered a bug or not.
It depends on what dup and idup are ultimately supposed to do.
- Jonathan M Davis
