On Monday, May 14, 2012 14:08:17 Gor Gyolchanyan wrote:
> Hi! I have a small question:
> Is the test for a null array equivalent to a test for zero-length array?
> This is particularly interesting for strings.
> For instance, I could return an empty string from a toString-like function
> and the empty string would be printed, but If I returned a null string,
> that would indicate, that there is no string representation and it would
> cause some default string to be printed.
> So, the question is, if a null array is any different from an empty array?

A null array is equal to an empty array.

assert(null == []);
assert(null == "");

It's when you use is that things change. An array "is null" only if it's ptr property is null, which is true only for uninitialized arrays and [] (the compiler doesn't bother allocating memory for [], so it's basically the same as null). However, since "" is a string literal, it _does_ have memory allocated to it, so

assert([] is null);
assert("" !is null);

So, it all comes down to the ptr property. An array is considered to have a length of 0 if its length property is 0 (which null arrays do). It's only considered to be null if its ptr property is null. == uses the length property, ignoring the ptr property as long as the lengths are equal (and checking each of the elements refered to by the ptr property if the lengths aren't equal), whereas is specifically checks whether the ptr properties of the two arrays are equal.

Personally, I think that conflating null and empty like this is atrocious, but that's how the language works, and we're stuck with it.

- Jonathan M Davis

At least we could make an empty string a null array of characters for consistency. How many times did anyone use the feature of string literals being null-terminated?

On Mon, May 14, 2012 at 8:56 PM, Jonathan M Davis <jmdavisProg@gmx.com>wrote:

> On Monday, May 14, 2012 14:08:17 Gor Gyolchanyan wrote:
> > Hi! I have a small question:
> > Is the test for a null array equivalent to a test for zero-length array?
> > This is particularly interesting for strings.
> > For instance, I could return an empty string from a toString-like
> function
> > and the empty string would be printed, but If I returned a null string,
> > that would indicate, that there is no string representation and it would
> > cause some default string to be printed.
> > So, the question is, if a null array is any different from an empty
> array?
>
> A null array is equal to an empty array.
>
> assert(null == []);
> assert(null == "");
>
> It's when you use is that things change. An array "is null" only if it's
> ptr
> property is null, which is true only for uninitialized arrays and [] (the
> compiler doesn't bother allocating memory for [], so it's basically the
> same
> as null). However, since "" is a string literal, it _does_ have memory
> allocated to it, so
>
> assert([] is null);
> assert("" !is null);
>
> So, it all comes down to the ptr property. An array is considered to have a
> length of 0 if its length property is 0 (which null arrays do). It's only
> considered to be null if its ptr property is null. == uses the length
> property, ignoring the ptr property as long as the lengths are equal (and
> checking each of the elements refered to by the ptr property if the lengths
> aren't equal), whereas is specifically checks whether the ptr properties
> of the
> two arrays are equal.
>
> Personally, I think that conflating null and empty like this is atrocious,
> but
> that's how the language works, and we're stuck with it.
>
> - Jonathan M Davis
>



-- 
Bye,
Gor Gyolchanyan.

On 14-05-2012 19:16, Gor Gyolchanyan wrote:
> At least we could make an empty string a null array of characters for
> consistency. How many times did anyone use the feature of string
> literals being null-terminated?
>
> On Mon, May 14, 2012 at 8:56 PM, Jonathan M Davis <jmdavisProg@gmx.com
> <mailto:jmdavisProg@gmx.com>> wrote:
>
>     On Monday, May 14, 2012 14:08:17 Gor Gyolchanyan wrote:
>      > Hi! I have a small question:
>      > Is the test for a null array equivalent to a test for zero-length
>     array?
>      > This is particularly interesting for strings.
>      > For instance, I could return an empty string from a toString-like
>     function
>      > and the empty string would be printed, but If I returned a null
>     string,
>      > that would indicate, that there is no string representation and
>     it would
>      > cause some default string to be printed.
>      > So, the question is, if a null array is any different from an
>     empty array?
>
>     A null array is equal to an empty array.
>
>     assert(null == []);
>     assert(null == "");
>
>     It's when you use is that things change. An array "is null" only if
>     it's ptr
>     property is null, which is true only for uninitialized arrays and []
>     (the
>     compiler doesn't bother allocating memory for [], so it's basically
>     the same
>     as null). However, since "" is a string literal, it _does_ have memory
>     allocated to it, so
>
>     assert([] is null);
>     assert("" !is null);
>
>     So, it all comes down to the ptr property. An array is considered to
>     have a
>     length of 0 if its length property is 0 (which null arrays do). It's
>     only
>     considered to be null if its ptr property is null. == uses the length
>     property, ignoring the ptr property as long as the lengths are equal
>     (and
>     checking each of the elements refered to by the ptr property if the
>     lengths
>     aren't equal), whereas is specifically checks whether the ptr
>     properties of the
>     two arrays are equal.
>
>     Personally, I think that conflating null and empty like this is
>     atrocious, but
>     that's how the language works, and we're stuck with it.
>
>     - Jonathan M Davis
>
>
>
>
> --
> Bye,
> Gor Gyolchanyan.

See my other post in reply to your original thread.

-- 
- Alex

On Monday, May 14, 2012 21:16:21 Gor Gyolchanyan wrote:
> At least we could make an empty string a null array of characters for consistency.

It's completely consintent. If there is memory allocated for the array, then it's ptr property is non-null, and then the array is non-null per the is operator. If there is no memory allocated for the array, then it's ptr property is null, and the array is null per the is operator.

It's quite possible to have non-string arrays be non-null with a length of 0. It just takes more work. e.g.

auto a = new int[](1);
a.length = 0;

And it would actually be really annoying if "" were treated the same as [], because it becomes harder to differentiate between the empty string and a null string in the few cases where you care. If anything, the fact that [] doesn't allocate is _more_ annoying as far as that goes. But it's more efficient that way, so that's why [] is null.

> How many times did anyone use the feature of string literals being null-terminated?

It gets used all the time when people call C functions and is a _really_ good reason why making assert("" is null) true would be a _really_ bad idea.

- Jonathan M Davis


P.S. Please don't top-post. It's bad etiquette and makes posts harder to follow.

>> P.S. Please don't top-post. It's bad etiquette and makes posts harder to
follow.

It's not me. It's how gmail works.

On Tue, May 15, 2012 at 12:12 AM, Jonathan M Davis <jmdavisProg@gmx.com>wrote:

> On Monday, May 14, 2012 21:16:21 Gor Gyolchanyan wrote:
> > At least we could make an empty string a null array of characters for consistency.
>
> It's completely consintent. If there is memory allocated for the array,
> then
> it's ptr property is non-null, and then the array is non-null per the is
> operator. If there is no memory allocated for the array, then it's ptr
> property is null, and the array is null per the is operator.
>
> It's quite possible to have non-string arrays be non-null with a length of
> 0.
> It just takes more work. e.g.
>
> auto a = new int[](1);
> a.length = 0;
>
> And it would actually be really annoying if "" were treated the same as [],
> because it becomes harder to differentiate between the empty string and a
> null
> string in the few cases where you care. If anything, the fact that []
> doesn't
> allocate is _more_ annoying as far as that goes. But it's more efficient
> that
> way, so that's why [] is null.
>
> > How many times did anyone use the feature of string literals being null-terminated?
>
> It gets used all the time when people call C functions and is a _really_
> good
> reason why making assert("" is null) true would be a _really_ bad idea.
>
> - Jonathan M Davis
>
>
> P.S. Please don't top-post. It's bad etiquette and makes posts harder to follow.
>



-- 
Bye,
Gor Gyolchanyan.

On 05/14/2012 07:16 PM, Gor Gyolchanyan wrote:
> At least we could make an empty string a null array of characters for
> consistency. How many times did anyone use the feature of string
> literals being null-terminated?
>

It is a useful feature. There is no reason to break

printf("Hello, World!");

There's not reason to use printf! This is ridiculous! We haev a type-safe
writef, which does exactly that and does it better.
Besides, wrapping the literal into a toUTFz is not too difficult!

On Tue, May 15, 2012 at 2:15 AM, Timon Gehr <timon.gehr@gmx.ch> wrote:

> On 05/14/2012 07:16 PM, Gor Gyolchanyan wrote:
>
>> At least we could make an empty string a null array of characters for consistency. How many times did anyone use the feature of string literals being null-terminated?
>>
>>
> It is a useful feature. There is no reason to break
>
> printf("Hello, World!");
>



-- 
Bye,
Gor Gyolchanyan.

On Tue, May 15, 2012 at 2:34 AM, Jonathan M Davis <jmdavisProg@gmx.com>wrote:

> On Tuesday, May 15, 2012 00:48:41 Gor Gyolchanyan wrote:
> > >> P.S. Please don't top-post. It's bad etiquette and makes posts harder
> to
> > >> follow.
> >
> > It's not me. It's how gmail works.
>
> Just because gmail puts your cursor at the top of your reply by default doesn't mean that you have to write your reply that way.
>
> - Jonathan M Davis
>

I'll try not to forget moving it down.

-- 
Bye,
Gor Gyolchanyan.

On 15-05-2012 12:09, Gor Gyolchanyan wrote:
> There's not reason to use printf! This is ridiculous! We haev a
> type-safe writef, which does exactly that and does it better.
> Besides, wrapping the literal into a toUTFz is not too difficult!
>
> On Tue, May 15, 2012 at 2:15 AM, Timon Gehr <timon.gehr@gmx.ch
> <mailto:timon.gehr@gmx.ch>> wrote:
>
>     On 05/14/2012 07:16 PM, Gor Gyolchanyan wrote:
>
>         At least we could make an empty string a null array of
>         characters for
>         consistency. How many times did anyone use the feature of string
>         literals being null-terminated?
>
>
>     It is a useful feature. There is no reason to break
>
>     printf("Hello, World!");
>
>
>
>
> --
> Bye,
> Gor Gyolchanyan.

Yes, because using a Phobos function in druntime is perfectly possible! Totally!

-- 
- Alex

On Tue, May 15, 2012 at 4:00 PM, Alex Rønne Petersen <xtzgzorex@gmail.com>wrote:

>
> Yes, because using a Phobos function in druntime is perfectly possible! Totally!
>  --
> - Alex
>

Isn't it obvious what needs to be done? Come on, it's no too hard to see...


-- 
Bye,
Gor Gyolchanyan.