Re: arrays: if(null == [ ])

[Marco Leise]

Am Wed, 16 May 2012 09:18:38 -0400
schrieb "Steven Schveighoffer" :

> Regardless, we should fix if(!arr) to mean if(!arr.length).
> 
> -Steve

I'm still using 2.057 (GDC). My mental model of D tells me: A reference type's 
pointer is implicitly converted to bool, when used inside an if-expression.

These are equal statements for any reference type:

if(reference_type is null)
if(!(reference_type !is null))
if(!reference_type)

As an example, I use the these semantics and they feel correct to me. Look at 
this example where a solution set is expressed as a long[]:

long[] empty_solution = [];
assert(empty_solution); // the solution set is empty (a = a + 42)
long[] no_solution = null;
assert(!no_solution);   // a solution is not computable (a = a)

The shortest form is also the most basic one: Do we have a solution set at all?
Once I'm past the 'existence' check, I'd look at the length: if 
(solution.length == 1) ...
In other use cases you make no distinction between "is null" and "length == 0". 
For those it is ok to check "if (arr.length)", but I want to make you aware 
that both cases exist and I think the way it worked in 2.057 was consistent.

Now with 2.059 I have to turn a solution set into a structure with a flag like 
'solved'. The language got less expressive here. If that's how it is going too 
stay then yes, "if(arr)" should really mean "if(arr.length)", because the only 
time it is not the same is when the language accidentally exposes the 
implementation detail that an empty string actually needs memory. :)

-- 
Marco

Re: arrays: if(null == [ ])

[Regan Heath]

On Thu, 17 May 2012 00:08:49 +0100, Jonathan M Davis   
wrote:



On Wednesday, May 16, 2012 09:18:38 Steven Schveighoffer wrote:

but I still think we should discourage using null as a
sentinel, it leads to confusing code.


If null were actually properly differentiated from empty, then this  
wouldn't be
a problem, but it's not. It _should_ be possible to treat null as a  
sentinel.
The fact that it causes issues is a major flaw in the language IMHO. But  
given
that flaw, it does very quickly become error-prone to use null as a  
sentinel.
In general, I'd say that the only reasonable place to do so is when  
returning
an array (and especially a string) from a function. The return value can  
then
be immeditely checked with is null before it has the chance to have  
something

happen to it which could cause it to be empty but non-null.


I want to re-re-re-register my dismay in the situation also.  For me it  
always comes back to.. I can do it with a pointer.. a pointer!  Why not an  
array?!?


R

--
Using Opera's revolutionary email client: http://www.opera.com/mail/

Re: arrays: if(null == [ ])

[deadalnix]

Le 16/05/2012 23:15, Steven Schveighoffer a écrit :

On Wed, 16 May 2012 17:11:58 -0400, deadalnix  wrote:


Le 16/05/2012 15:12, Steven Schveighoffer a écrit :

On Tue, 15 May 2012 04:42:10 -0400, deadalnix 
wrote:


Le 14/05/2012 21:53, Steven Schveighoffer a écrit :

On Mon, 14 May 2012 15:30:25 -0400, deadalnix 
wrote:


Le 14/05/2012 16:37, Steven Schveighoffer a écrit :

Note that [] is a request to the runtime to build an empty array.
The
runtime detects this, and rather than consuming a heap allocation to
build nothing, it simply returns a null-pointed array. This is 100%
the
right decision, and I don't think anyone would ever convince me (or
Andrei or Walter) otherwise.



Obviously this is the right thing to do !

The question is why an array of length 0 isn't nulled ? It lead to
confusing semantic here, and can keep alive memory that can't be
accessed.


int[] arr;
arr.reserve(1);
assert(arr.length == 0);

-Steve


The length isn't set to 0 here. You obviously don't want that to be
nulled.


The assert disagrees with you :)

-Steve


The length IS 0. It IS 0 before the call to reserve. It is never SET
to 0.


OK, so it's allowed to be 0 and not-null. doesn't this lead to the
confusing semantics you were talking about?

What about this?

int[] arr;
arr.reserve(1);

int[] arr2 = [1,2,3];
arr2 = arr; // now length has been *set* to 0, should it also be nulled?

But I want arr2 and arr to point at the same thing, maybe I'm not using
arr anymore. Maybe I returned it from a function, and I no longer have
access to arr.

-Steve


That make sense :D

Re: arrays: if(null == [ ])

[Jonathan M Davis]

On Wednesday, May 16, 2012 09:18:38 Steven Schveighoffer wrote:
> but I still think we should discourage using null as a
> sentinel, it leads to confusing code.

If null were actually properly differentiated from empty, then this wouldn't be 
a problem, but it's not. It _should_ be possible to treat null as a sentinel. 
The fact that it causes issues is a major flaw in the language IMHO. But given 
that flaw, it does very quickly become error-prone to use null as a sentinel. 
In general, I'd say that the only reasonable place to do so is when returning 
an array (and especially a string) from a function. The return value can then 
be immeditely checked with is null before it has the chance to have something 
happen to it which could cause it to be empty but non-null.

- Jonathan M Davis

Re: arrays: if(null == [ ])

[Steven Schveighoffer]

On Wed, 16 May 2012 17:11:58 -0400, deadalnix  wrote:


Le 16/05/2012 15:12, Steven Schveighoffer a écrit :
On Tue, 15 May 2012 04:42:10 -0400, deadalnix   
wrote:



Le 14/05/2012 21:53, Steven Schveighoffer a écrit :

On Mon, 14 May 2012 15:30:25 -0400, deadalnix 
wrote:


Le 14/05/2012 16:37, Steven Schveighoffer a écrit :
Note that [] is a request to the runtime to build an empty array.  
The

runtime detects this, and rather than consuming a heap allocation to
build nothing, it simply returns a null-pointed array. This is 100%
the
right decision, and I don't think anyone would ever convince me (or
Andrei or Walter) otherwise.



Obviously this is the right thing to do !

The question is why an array of length 0 isn't nulled ? It lead to
confusing semantic here, and can keep alive memory that can't be
accessed.


int[] arr;
arr.reserve(1);
assert(arr.length == 0);

-Steve


The length isn't set to 0 here. You obviously don't want that to be
nulled.


The assert disagrees with you :)

-Steve


The length IS 0. It IS 0 before the call to reserve. It is never SET to  
0.


OK, so it's allowed to be 0 and not-null.  doesn't this lead to the  
confusing semantics you were talking about?


What about this?

int[] arr;
arr.reserve(1);

int[] arr2 = [1,2,3];
arr2 = arr; // now length has been *set* to 0, should it also be nulled?

But I want arr2 and arr to point at the same thing, maybe I'm not using  
arr anymore.  Maybe I returned it from a function, and I no longer have  
access to arr.


-Steve

Re: arrays: if(null == [ ])

[deadalnix]

Le 16/05/2012 15:12, Steven Schveighoffer a écrit :

On Tue, 15 May 2012 04:42:10 -0400, deadalnix  wrote:


Le 14/05/2012 21:53, Steven Schveighoffer a écrit :

On Mon, 14 May 2012 15:30:25 -0400, deadalnix 
wrote:


Le 14/05/2012 16:37, Steven Schveighoffer a écrit :

Note that [] is a request to the runtime to build an empty array. The
runtime detects this, and rather than consuming a heap allocation to
build nothing, it simply returns a null-pointed array. This is 100%
the
right decision, and I don't think anyone would ever convince me (or
Andrei or Walter) otherwise.



Obviously this is the right thing to do !

The question is why an array of length 0 isn't nulled ? It lead to
confusing semantic here, and can keep alive memory that can't be
accessed.


int[] arr;
arr.reserve(1);
assert(arr.length == 0);

-Steve


The length isn't set to 0 here. You obviously don't want that to be
nulled.


The assert disagrees with you :)

-Steve


The length IS 0. It IS 0 before the call to reserve. It is never SET to 0.

Re: arrays: if(null == [ ])

[Timon Gehr]

On 05/16/2012 04:23 PM, bearophile wrote:

 Is this request in Bugzilla?


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

The first report happens to be yours =).

Re: arrays: if(null == [ ])

[Tobias Pankrath]

On Wednesday, 16 May 2012 at 14:26:49 UTC, Alex Rønne Petersen 
wrote:

On 16-05-2012 16:23, bearophile wrote:

Steven Schveighoffer:


Regardless, we should fix if(!arr) to mean if(!arr.length).


This seems a nice idea (and Python programmers will be 
thankful, because
they are used to empty collections/strings to be false). Is 
this request
in Bugzilla? Are people opposed to this little D breaking 
change?


Bye,
bearophile


I would be very happy about this change, too.


I ran into this, too.

Re: arrays: if(null == [ ])

[Alex Rønne Petersen]

On 16-05-2012 16:23, bearophile wrote:

Steven Schveighoffer:


Regardless, we should fix if(!arr) to mean if(!arr.length).


This seems a nice idea (and Python programmers will be thankful, because
they are used to empty collections/strings to be false). Is this request
in Bugzilla? Are people opposed to this little D breaking change?

Bye,
bearophile


I would be very happy about this change, too.

--
Alex Rønne Petersen
a...@lycus.org
http://lycus.org

Re: arrays: if(null == [ ])

[bearophile]

Steven Schveighoffer:


Regardless, we should fix if(!arr) to mean if(!arr.length).


This seems a nice idea (and Python programmers will be thankful, 
because they are used to empty collections/strings to be false). 
Is this request in Bugzilla? Are people opposed to this little D 
breaking change?


Bye,
bearophile

Re: arrays: if(null == [ ])

[Steven Schveighoffer]

On Mon, 14 May 2012 18:07:24 -0400, Timon Gehr  wrote:


On 05/14/2012 01:51 PM, deadalnix wrote:

Le 14/05/2012 12:49, Gor Gyolchanyan a écrit :

So, null arrays and empty arrays are always the same, except for an
empty string, which is a valid non-nill array of characters with length
0, right?



If it is the current behavior, it deserve a WAT !


I agree, but it is explained easily. Built-in string literals are always  
zero-terminated, therefore an empty string literal must point into  
accessible memory. I'd like to have [] !is null as well, so that null  
can reliably be used as a sentinel value.


This would mean either a) allocating memory for a 0 length array, or b)  
pointing it at non-null but non-heap memory.


a) is certainly out of the question.

b) is possible, but I still think we should discourage using null as a  
sentinel, it leads to confusing code.


Regardless, we should fix if(!arr) to mean if(!arr.length).

-Steve

Re: arrays: if(null == [ ])

[Steven Schveighoffer]

On Tue, 15 May 2012 04:42:10 -0400, deadalnix  wrote:


Le 14/05/2012 21:53, Steven Schveighoffer a écrit :
On Mon, 14 May 2012 15:30:25 -0400, deadalnix   
wrote:



Le 14/05/2012 16:37, Steven Schveighoffer a écrit :

Note that [] is a request to the runtime to build an empty array. The
runtime detects this, and rather than consuming a heap allocation to
build nothing, it simply returns a null-pointed array. This is 100%  
the

right decision, and I don't think anyone would ever convince me (or
Andrei or Walter) otherwise.



Obviously this is the right thing to do !

The question is why an array of length 0 isn't nulled ? It lead to
confusing semantic here, and can keep alive memory that can't be
accessed.


int[] arr;
arr.reserve(1);
assert(arr.length == 0);

-Steve


The length isn't set to 0 here. You obviously don't want that to be  
nulled.


The assert disagrees with you :)

-Steve

Re: arrays: if(null == [ ])

[Jonathan M Davis]

On Wednesday, May 16, 2012 00:48:44 Gor Gyolchanyan wrote:
> No, no and no. toUTFz could be called at compile-time. Absolutely no extra
> run-time allocations, absolutely no run-time overhead.

So, you're going to create a bunch of enums just to pass string literals to C 
functions? Stuff like this happens all the time when interfacing with C code

func("hello world", 5, someVar);

I really don't see why it would be desirable to make

assert("" is null);

pass. And I _really_ don't see a problem with string literals being zero-
terminated. It makes dealing with them easier, and changing it would break a 
lot of code.

- Jonathan M Davis

Re: arrays: if(null == [ ])

[Andrej Mitrovic]

On 5/15/12, Gor Gyolchanyan  wrote:
> No, no and no. toUTFz could be called at compile-time. Absolutely no extra
> run-time allocations, absolutely no run-time overhead.

How about programmer-time overhead? Are *you* volunteering to edit all
the codebases out there that rely on having 0-terminated string
literals?

Re: arrays: if(null == [ ])

[deadalnix]

Le 15/05/2012 15:29, Alex Rønne Petersen a écrit :

On 15-05-2012 15:22, Gor Gyolchanyan wrote:

On Tue, May 15, 2012 at 4:00 PM, Alex Rønne Petersen
mailto:xtzgzo...@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.


No, it should not be moved to druntime. druntime is the low-level
abstraction layer over the compiler, nothing else.

Further, all the write* functions perform GC allocation, which is
unacceptable in druntime.



I do agree that it does not belong to druntime.

However :
1/ druntime already perfom GC aloc.
2/ druntime isn't supposed to printf anyway.

Re: arrays: if(null == [ ])

[Gor Gyolchanyan]

No, no and no. toUTFz could be called at compile-time. Absolutely no extra
run-time allocations, absolutely no run-time overhead.

On Tue, May 15, 2012 at 11:05 PM, Jonathan M Davis wrote:

> On Tuesday, May 15, 2012 17:35:58 Gor Gyolchanyan wrote:
> > Even if it's wrong to move writef to druntime, the toUTFz is still a very
> > small word to write.
>
> Using toStringz or toUTFz instead of having string literals be
> zero-terminated
> would force allocating extra strings (string literals are in an RO portion
> of
> memory - at least on Linux - so you can't append to them without
> reallocating).
>
> Making it so that string literals weren't null terminated would break a
> _lot_
> of code for little-to-no benefit and a definite cost. I really don't see
> the
> problem with "" being different from cast(string)[] - particularly when the
> fact that "" is non-null is _useful_.
>
> - Jonathan M Davis
>



-- 
Bye,
Gor Gyolchanyan.

Re: arrays: if(null == [ ])

[Jonathan M Davis]

On Tuesday, May 15, 2012 17:35:58 Gor Gyolchanyan wrote:
> Even if it's wrong to move writef to druntime, the toUTFz is still a very
> small word to write.

Using toStringz or toUTFz instead of having string literals be zero-terminated 
would force allocating extra strings (string literals are in an RO portion of 
memory - at least on Linux - so you can't append to them without 
reallocating).

Making it so that string literals weren't null terminated would break a _lot_ 
of code for little-to-no benefit and a definite cost. I really don't see the 
problem with "" being different from cast(string)[] - particularly when the 
fact that "" is non-null is _useful_.

- Jonathan M Davis

Re: arrays: if(null == [ ])

[Timon Gehr]

On 05/15/2012 12:09 PM, 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!

Re: arrays: if(null == [ ])

[Gor Gyolchanyan]

UTF manipulation functions are fundamental enough, because all of D's
strings are UTF-something.
I think std.utf deserves to be in druntime.

On Tue, May 15, 2012 at 6:05 PM, Alex Rønne Petersen wrote:

> On 15-05-2012 15:35, Gor Gyolchanyan wrote:
>
>> Even if it's wrong to move writef to druntime, the toUTFz is still a
>> very small word to write.
>>
>> On Tue, May 15, 2012 at 5:29 PM, Alex Rønne Petersen
>>
>> mailto:xtzgzo...@gmail.com>> wrote:
>>
>>On 15-05-2012 15:22, Gor Gyolchanyan wrote:
>>
>>On Tue, May 15, 2012 at 4:00 PM, Alex Rønne Petersen
>>mailto:xtzgzo...@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.
>>
>>
>>No, it should not be moved to druntime. druntime is the low-level
>>abstraction layer over the compiler, nothing else.
>>
>>Further, all the write* functions perform GC allocation, which is
>>unacceptable in druntime.
>>
>>--
>>- Alex
>>
>>
>>
>>
>> --
>> Bye,
>> Gor Gyolchanyan.
>>
>
> It's a Phobos function.
>
> --
> - Alex
>



-- 
Bye,
Gor Gyolchanyan.

Re: arrays: if(null == [ ])

[Alex Rønne Petersen]

On 15-05-2012 15:35, Gor Gyolchanyan wrote:

Even if it's wrong to move writef to druntime, the toUTFz is still a
very small word to write.

On Tue, May 15, 2012 at 5:29 PM, Alex Rønne Petersen
mailto:xtzgzo...@gmail.com>> wrote:

On 15-05-2012 15:22, Gor Gyolchanyan wrote:

On Tue, May 15, 2012 at 4:00 PM, Alex Rønne Petersen
mailto:xtzgzo...@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.


No, it should not be moved to druntime. druntime is the low-level
abstraction layer over the compiler, nothing else.

Further, all the write* functions perform GC allocation, which is
unacceptable in druntime.

--
- Alex




--
Bye,
Gor Gyolchanyan.


It's a Phobos function.

--
- Alex

Re: arrays: if(null == [ ])

[Gor Gyolchanyan]

Even if it's wrong to move writef to druntime, the toUTFz is still a very
small word to write.

On Tue, May 15, 2012 at 5:29 PM, Alex Rønne Petersen wrote:

> On 15-05-2012 15:22, Gor Gyolchanyan wrote:
>
>> On Tue, May 15, 2012 at 4:00 PM, Alex Rønne Petersen
>> mailto:xtzgzo...@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.
>>
>
> No, it should not be moved to druntime. druntime is the low-level
> abstraction layer over the compiler, nothing else.
>
> Further, all the write* functions perform GC allocation, which is
> unacceptable in druntime.
>
> --
> - Alex
>



-- 
Bye,
Gor Gyolchanyan.

Re: arrays: if(null == [ ])

[Alex Rønne Petersen]

On 15-05-2012 15:22, Gor Gyolchanyan wrote:

On Tue, May 15, 2012 at 4:00 PM, Alex Rønne Petersen
mailto:xtzgzo...@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.


No, it should not be moved to druntime. druntime is the low-level 
abstraction layer over the compiler, nothing else.


Further, all the write* functions perform GC allocation, which is 
unacceptable in druntime.


--
- Alex

Re: arrays: if(null == [ ])

[Gor Gyolchanyan]

On Tue, May 15, 2012 at 4:00 PM, Alex Rønne Petersen 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.

Re: arrays: if(null == [ ])

[Alex Rønne Petersen]

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 mailto:timon.g...@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

Re: arrays: if(null == [ ])

[Gor Gyolchanyan]

On Tue, May 15, 2012 at 2:34 AM, Jonathan M Davis 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.

Re: arrays: if(null == [ ])

[Gor Gyolchanyan]

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  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.

Re: arrays: if(null == [ ])

[deadalnix]

Le 14/05/2012 21:53, Steven Schveighoffer a écrit :

On Mon, 14 May 2012 15:30:25 -0400, deadalnix  wrote:


Le 14/05/2012 16:37, Steven Schveighoffer a écrit :

Note that [] is a request to the runtime to build an empty array. The
runtime detects this, and rather than consuming a heap allocation to
build nothing, it simply returns a null-pointed array. This is 100% the
right decision, and I don't think anyone would ever convince me (or
Andrei or Walter) otherwise.



Obviously this is the right thing to do !

The question is why an array of length 0 isn't nulled ? It lead to
confusing semantic here, and can keep alive memory that can't be
accessed.


int[] arr;
arr.reserve(1);
assert(arr.length == 0);

-Steve


The length isn't set to 0 here. You obviously don't want that to be nulled.

Re: arrays: if(null == [ ])

[Jonathan M Davis]

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

Re: arrays: if(null == [ ])

[Timon Gehr]

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!");

Re: arrays: if(null == [ ])

[Timon Gehr]

On 05/14/2012 01:51 PM, deadalnix wrote:

Le 14/05/2012 12:49, Gor Gyolchanyan a écrit :

So, null arrays and empty arrays are always the same, except for an
empty string, which is a valid non-nill array of characters with length
0, right?



If it is the current behavior, it deserve a WAT !


I agree, but it is explained easily. Built-in string literals are always 
zero-terminated, therefore an empty string literal must point into 
accessible memory. I'd like to have [] !is null as well, so that null 
can reliably be used as a sentinel value.

Re: arrays: if(null == [ ])

[Gor Gyolchanyan]

>> 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 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.

Re: arrays: if(null == [ ])

[Jonathan M Davis]

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.

Re: arrays: if(null == [ ])

[Steven Schveighoffer]

On Mon, 14 May 2012 15:30:25 -0400, deadalnix  wrote:


Le 14/05/2012 16:37, Steven Schveighoffer a écrit :

Note that [] is a request to the runtime to build an empty array. The
runtime detects this, and rather than consuming a heap allocation to
build nothing, it simply returns a null-pointed array. This is 100% the
right decision, and I don't think anyone would ever convince me (or
Andrei or Walter) otherwise.



Obviously this is the right thing to do !

The question is why an array of length 0 isn't nulled ? It lead to  
confusing semantic here, and can keep alive memory that can't be  
accessed.


int[] arr;
arr.reserve(1);
assert(arr.length == 0);

-Steve

Re: arrays: if(null == [ ])

[deadalnix]

Le 14/05/2012 16:37, Steven Schveighoffer a écrit :

Note that [] is a request to the runtime to build an empty array. The
runtime detects this, and rather than consuming a heap allocation to
build nothing, it simply returns a null-pointed array. This is 100% the
right decision, and I don't think anyone would ever convince me (or
Andrei or Walter) otherwise.



Obviously this is the right thing to do !

The question is why an array of length 0 isn't nulled ? It lead to 
confusing semantic here, and can keep alive memory that can't be accessed.

Re: arrays: if(null == [ ])

[Gor Gyolchanyan]

This is the original thread and there's no reply from you prior to this one.

On Mon, May 14, 2012 at 9:41 PM, Alex Rønne Petersen wrote:

> 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 > > 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
>



-- 
Bye,
Gor Gyolchanyan.

Re: arrays: if(null == [ ])

[Alex Rønne Petersen]

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 mailto:jmdavisp...@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

Re: arrays: if(null == [ ])

[Gor Gyolchanyan]

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 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.

Re: arrays: if(null == [ ])

[Jonathan M Davis]

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

Re: arrays: if(null == [ ])

[Steven Schveighoffer]

On Mon, 14 May 2012 06:08:17 -0400, Gor Gyolchanyan  
 wrote:



Hi! I have a small question:
Is the test for a null array equivalent to a test for zero-length array?


== tests for length and content equivalence.

'is' tests for both pointer and length equivalence (and therefore, content  
equality is implied).


There is a large confusion with null arrays.  A null array is simply an  
empty array that happens to be pointing to null.  Other than that, it is  
equivalent to an empty array, and should be treated as such.


One can use the idea that "null arrays are special", but it leads to  
likely confusing semantics, where an empty array is different from a null  
array.  if(arr) should IMO succeed iff length > 0.  That is one of the  
main reasons of the confusion.


Note that [] is a request to the runtime to build an empty array.  The  
runtime detects this, and rather than consuming a heap allocation to build  
nothing, it simply returns a null-pointed array.  This is 100% the right  
decision, and I don't think anyone would ever convince me (or Andrei or  
Walter) otherwise.



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.


These are the confusing semantics I was referring to ;)  I would recommend  
we try to avoid this kind of distinction wherever possible.


So, the question is, if a null array is any different from an empty  
array?


I would say it technically is different, but you should treat it as  
equivalent unless you have a really really good reason not to.  It's just  
another empty array which happens to be pointing at 0.


-Steve

Re: arrays: if(null == [ ])

[Gor Gyolchanyan]

No, it doesn't. Appending to a null array is equivalent to allocating a new
array.

On Mon, May 14, 2012 at 6:29 PM, H. S. Teoh  wrote:

> On Mon, May 14, 2012 at 05:00:25PM +0400, Gor Gyolchanyan wrote:
> > I think any kind of null array should be different from an array of
> > zero length.
>
> But that defeats the utility of idioms like:
>
>int[] arr;
>arr ~= 123;
>...
>
>
> T
>
> --
> There are four kinds of lies: lies, damn lies, and statistics.
>



-- 
Bye,
Gor Gyolchanyan.

Re: arrays: if(null == [ ])

[H. S. Teoh]

On Mon, May 14, 2012 at 05:00:25PM +0400, Gor Gyolchanyan wrote:
> I think any kind of null array should be different from an array of
> zero length.

But that defeats the utility of idioms like:

int[] arr;
arr ~= 123;
...


T

-- 
There are four kinds of lies: lies, damn lies, and statistics.

Re: arrays: if(null == [ ])

[Gor Gyolchanyan]

I think any kind of null array should be different from an array of zero
length.

On Mon, May 14, 2012 at 3:55 PM, simendsjo  wrote:

> On Mon, 14 May 2012 13:51:40 +0200, deadalnix  wrote:
>
>  Le 14/05/2012 12:49, Gor Gyolchanyan a écrit :
>>
>>> So, null arrays and empty arrays are always the same, except for an
>>> empty string, which is a valid non-nill array of characters with length
>>> 0, right?
>>>
>>>
>> If it is the current behavior, it deserve a WAT !
>>
>
> It is according to my tests.. It's quite a gotcha.
> So check for .length or == "" or == [] if you need "null or empty" and use
> "is null" for null/[]
>



-- 
Bye,
Gor Gyolchanyan.

Re: arrays: if(null == [ ])

[simendsjo]

On Mon, 14 May 2012 13:51:40 +0200, deadalnix  wrote:


Le 14/05/2012 12:49, Gor Gyolchanyan a écrit :

So, null arrays and empty arrays are always the same, except for an
empty string, which is a valid non-nill array of characters with length
0, right?



If it is the current behavior, it deserve a WAT !


It is according to my tests.. It's quite a gotcha.
So check for .length or == "" or == [] if you need "null or empty" and use  
"is null" for null/[]

Re: arrays: if(null == [ ])

[deadalnix]

Le 14/05/2012 12:49, Gor Gyolchanyan a écrit :

So, null arrays and empty arrays are always the same, except for an
empty string, which is a valid non-nill array of characters with length
0, right?



If it is the current behavior, it deserve a WAT !

Re: arrays: if(null == [ ])

[Gor Gyolchanyan]

So, null arrays and empty arrays are always the same, except for an empty
string, which is a valid non-nill array of characters with length 0, right?

On Mon, May 14, 2012 at 2:24 PM, simendsjo  wrote:

> On Mon, 14 May 2012 12:08:17 +0200, Gor Gyolchanyan <
> gor.f.gyolchan...@gmail.com> 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?
>>
>>
> This passes. null and [] is a null string, but "" gives a non-null string.
> Tested on dmd-head and 2.059.
>
> void main() {
>string s1 = null;
>assert(s1 is null);
>assert(s1.length == 0);
>assert(s1.ptr is null);
>assert(s1 == []);
>assert(s1 == "");
>
>string s2 = [];
>assert(s2 is null);
>assert(s2.length == 0);
>assert(s2.ptr is null);
>assert(s2 == []);
>assert(s2 == "");
>
>string s3 = "";
>assert(s3 !is null);
>assert(s3.length == 0);
>assert(s3.ptr !is null);
>assert(s3 == []);
>assert(s3 == "");
> }
>



-- 
Bye,
Gor Gyolchanyan.

Re: arrays: if(null == [ ])

[Simen Kjaeraas]

On Mon, 14 May 2012 12:08:17 +0200, 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?




The two are different, yes. [] == null actually compares length. If you
want to know if the length is zero, use arr.length. If you want to know if
it points to null, check if arr.ptr is null.

Re: arrays: if(null == [ ])

[simendsjo]

On Mon, 14 May 2012 12:08:17 +0200, 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?




This passes. null and [] is a null string, but "" gives a non-null string.  
Tested on dmd-head and 2.059.


void main() {
string s1 = null;
assert(s1 is null);
assert(s1.length == 0);
assert(s1.ptr is null);
assert(s1 == []);
assert(s1 == "");

string s2 = [];
assert(s2 is null);
assert(s2.length == 0);
assert(s2.ptr is null);
assert(s2 == []);
assert(s2 == "");

string s3 = "";
assert(s3 !is null);
assert(s3.length == 0);
assert(s3.ptr !is null);
assert(s3 == []);
assert(s3 == "");
}

arrays: if(null == [ ])

[Gor Gyolchanyan]

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?

-- 
Bye,
Gor Gyolchanyan.