www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - string <-> null/bool implicit conversion

reply =?UTF-8?B?Ik3DoXJjaW8=?= Martins" <marcioapm gmail.com> writes:
Hi!


string a = "";
string b;

writeln(a ? "a" : "null");
writeln(b ? "b" : "null");


This program outputs:
a
null



What?

I suppose this is by design, but are there any plans to deprecate 
this?

I understand this happens because in this context, string.ptr is 
evaluated, but should a string really have the semantics of 
string.ptr depending on the context?

Having 2 empty strings evaluate differently is very unintuitive 
and error-prone, in my opinion.
Aug 20 2015
next sibling parent reply "anonymous" <anonymous example.com> writes:
On Thursday, 20 August 2015 at 16:45:18 UTC, Márcio Martins wrote:

 Hi!


 string a = "";
 string b;

 writeln(a ? "a" : "null");
 writeln(b ? "b" : "null");


 This program outputs:
 a
 null



 What?

 I suppose this is by design, but are there any plans to 
 deprecate this?


A compiler change disallowing such use of arrays was done and 
then reverted. See 
<https://issues.dlang.org/show_bug.cgi?id=4733>. I haven't 
followed things closely enough to give you a good summary.
Aug 20 2015
parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, 20 August 2015 at 17:01:07 UTC, anonymous wrote:

 A compiler change disallowing such use of arrays was done and 
 then reverted. See 
 <https://issues.dlang.org/show_bug.cgi?id=4733>. I haven't 
 followed things closely enough to give you a good summary.


Basically, almost everyone wanted the change, but it broke some 
of Andrei and Vladamir's code, because they were actually relying 
on the current behavior (which most everyone thinks is 
error-prone), and that convinced Walter that it wasn't worth the 
code breakage. So, it was reverted.

- Jonathan M Davis
Aug 20 2015
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 08/20/2015 07:32 PM, Jonathan M Davis wrote:

 On Thursday, 20 August 2015 at 17:01:07 UTC, anonymous wrote:

 A compiler change disallowing such use of arrays was done and then
 reverted. See <https://issues.dlang.org/show_bug.cgi?id=4733>. I
 haven't followed things closely enough to give you a good summary.


 Basically, almost everyone wanted the change, but it broke some of
 Andrei and Vladamir's code, because they were actually relying on the
 current behavior (which most everyone thinks is error-prone), and that
 convinced Walter that it wasn't worth the code breakage. So, it was
 reverted.

 - Jonathan M Davis


I.e. this has been dealt with extremely poorly.
Aug 20 2015
prev sibling parent reply "Vladimir Panteleev" <thecybershadow.lists gmail.com> writes:
On Thursday, 20 August 2015 at 17:32:24 UTC, Jonathan M Davis 
wrote:

 On Thursday, 20 August 2015 at 17:01:07 UTC, anonymous wrote:

 A compiler change disallowing such use of arrays was done and 
 then reverted. See 
 <https://issues.dlang.org/show_bug.cgi?id=4733>. I haven't 
 followed things closely enough to give you a good summary.


 Basically, almost everyone wanted the change, but it broke some 
 of Andrei and Vladamir's code,


It broke a crapton of my code.

Also, at least spell my name right please.
Aug 21 2015
next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, 21 August 2015 at 13:54:04 UTC, Vladimir Panteleev 
wrote:

 Also, at least spell my name right please.


Sorry.

- Jonathan M Davis
Aug 21 2015
prev sibling next sibling parent =?UTF-8?B?Ik3DoXJjaW8=?= Martins" <marcioapm gmail.com> writes:
On Friday, 21 August 2015 at 13:54:04 UTC, Vladimir Panteleev 
wrote:

 On Thursday, 20 August 2015 at 17:32:24 UTC, Jonathan M Davis 
 wrote:

 On Thursday, 20 August 2015 at 17:01:07 UTC, anonymous wrote:

 A compiler change disallowing such use of arrays was done and 
 then reverted. See 
 <https://issues.dlang.org/show_bug.cgi?id=4733>. I haven't 
 followed things closely enough to give you a good summary.


 Basically, almost everyone wanted the change, but it broke 
 some of Andrei and Vladamir's code,


 It broke a crapton of my code.

 Also, at least spell my name right please.


It broke lots of code but, does it have to? It could just be 
deprecated for one or two releases instead, and give you and 
other people that upgrade compiler to adjust, right?
Aug 21 2015
prev sibling parent reply "David Nadlinger" <code klickverbot.at> writes:
On Friday, 21 August 2015 at 13:54:04 UTC, Vladimir Panteleev 
wrote:

 It broke a crapton of my code.


… in a way for which a fix is trivial to automate, even without a 
full-fledged parser.

  – David
Aug 21 2015
parent reply "Vladimir Panteleev" <thecybershadow.lists gmail.com> writes:
On Friday, 21 August 2015 at 16:55:18 UTC, David Nadlinger wrote:

 On Friday, 21 August 2015 at 13:54:04 UTC, Vladimir Panteleev 
 wrote:

 It broke a crapton of my code.


 … in a way for which a fix is trivial to automate, even without 
 a full-fledged parser.


Sure.

All things considered, I'm not really that much against the 
change, personally. It would be painful but not the end of the 
world. But I'm not the one who made the final decision, W&A did.

However, I'm not particularly happy when people go into denial 
mode and ignore or misrepresent facts when discussing the problem 
at hand, especially when doing so they single out people in the 
community in a negative way.

"This warning almost doesn't break any code!" Yes it flipping 
does. "It does break some code, but only in certain extremely 
specialized contexts like memory allocation!" No it's bleeping 
not. "Many of those warnings are probably actual bugs, you should 
fix your buggy code!" No, they quacking aren't. I just write code 
this way, because I find the empty/null distinction obvious and 
useful. Shocking, I know.
Aug 21 2015
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 08/21/2015 10:01 PM, Vladimir Panteleev wrote:

 I just write code this way, because I find the empty/null distinction
 obvious and useful. Shocking, I know.


One of the main reasons this might be considered "shocking" is because 
DMD does not cleanly make this distinction. [] is null.
Aug 21 2015
prev sibling next sibling parent reply "David Nadlinger" <code klickverbot.at> writes:
On Friday, 21 August 2015 at 20:01:21 UTC, Vladimir Panteleev 
wrote:

 "This warning almost doesn't break any code!"


It indeed doesn't break almost any code. Yours is quite the 
outlier.

  — David
Aug 21 2015
parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, 21 August 2015 at 21:13:35 UTC, David Nadlinger wrote:

 On Friday, 21 August 2015 at 20:01:21 UTC, Vladimir Panteleev 
 wrote:

 "This warning almost doesn't break any code!"


 It indeed doesn't break almost any code. Yours is quite the 
 outlier.


In general, it gets a bit interesting when a feature is useful if 
used correctly and gets used correctly by experts but generally 
screws up most programmers. For instance, the comma operator 
would be a case of that. If used correctly, it can be really 
useful, but it's so easy to misuse that it's generally considered 
bad practice to use it. And yet, I'm sure that there are folks 
out there who love it and use it correctly on a regular basis. 
That's not the norm though.

- Jonathan M Davis
Aug 21 2015
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 08/22/2015 12:04 AM, Jonathan M Davis wrote:

 On Friday, 21 August 2015 at 21:13:35 UTC, David Nadlinger wrote:

 On Friday, 21 August 2015 at 20:01:21 UTC, Vladimir Panteleev wrote:

 "This warning almost doesn't break any code!"


 It indeed doesn't break almost any code. Yours is quite the outlier.


 In general, it gets a bit interesting when a feature is useful if used
 correctly and gets used correctly by experts but generally screws up
 most programmers. For instance, the comma operator would be a case of
 that. If used correctly, it can be really useful, but it's so easy to
 misuse that it's generally considered bad practice to use it. And yet,
 I'm sure that there are folks out there who love it and use it correctly
 on a regular basis. That's not the norm though.

 - Jonathan M Davis


For the comma operator, I think it's pretty clear that the usage of ',' 
to separate components of a tuple would be more useful.

(With L-T-R evaluation, replacing usages of the comma operator is easy, 
e.g. 'a,b,c' becomes '(a,b,c)[$-1]', not to speak about the delegate 
option.)
Aug 22 2015
next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Saturday, 22 August 2015 at 21:23:19 UTC, Timon Gehr wrote:

 For the comma operator, I think it's pretty clear that the 
 usage of ',' to separate components of a tuple would be more 
 useful.

 (With L-T-R evaluation, replacing usages of the comma operator 
 is easy, e.g. 'a,b,c' becomes '(a,b,c)[$-1]', not to speak 
 about the delegate option.)


Which can be wrapped into a simple construct à la last(a, b, c) 
or similar.
Aug 22 2015
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 08/23/2015 01:09 AM, deadalnix wrote:

 On Saturday, 22 August 2015 at 21:23:19 UTC, Timon Gehr wrote:

 For the comma operator, I think it's pretty clear that the usage of
 ',' to separate components of a tuple would be more useful.

 (With L-T-R evaluation, replacing usages of the comma operator is
 easy, e.g. 'a,b,c' becomes '(a,b,c)[$-1]', not to speak about the
 delegate option.)


 Which can be wrapped into a simple construct à la last(a, b, c) or similar.


Which can even be force-inlined.
Aug 22 2015
prev sibling parent "Kagamin" <spam here.lot> writes:
On Saturday, 22 August 2015 at 21:23:19 UTC, Timon Gehr wrote:

 For the comma operator, I think it's pretty clear that the 
 usage of ',' to separate components of a tuple would be more 
 useful.



tuple, but not related to comma operator.
Aug 24 2015
prev sibling parent "Kagamin" <spam here.lot> writes:
On Friday, 21 August 2015 at 20:01:21 UTC, Vladimir Panteleev 
wrote:

 "This warning almost doesn't break any code!" Yes it flipping 
 does. "It does break some code, but only in certain extremely 
 specialized contexts like memory allocation!" No it's bleeping 
 not. "Many of those warnings are probably actual bugs, you 
 should fix your buggy code!" No, they quacking aren't. I just 
 write code this way, because I find the empty/null distinction 
 obvious and useful. Shocking, I know.


The distinction has its merits, but it shouldn't prevent you from 
seeing how it doesn't quite fit the D slice design.
Aug 24 2015
prev sibling next sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 8/20/15 12:45 PM, "=?UTF-8?B?Ik3DoXJjaW8=?= Martins\" 
<marcioapm gmail.com>\"" wrote:

 Hi!


 string a = "";
 string b;

 writeln(a ? "a" : "null");
 writeln(b ? "b" : "null");


 This program outputs:
 a
 null



 What?

 I suppose this is by design, but are there any plans to deprecate this?


The "truthiness" of an array says it's true ONLY if both the pointer and 
length are 0.

Yes, by design, and no, it won't be deprecated. In fact it was 
deprecated, but was reverted by the language designer as too costly in 
terms of code breakage.

The main reason why it caused issues is this nice idiom:

if(auto arr = someFunction())
{
    // use arr
}

This would HAVE to be split out to two statements, and the arr variable 
would be scoped outside of the if statement.


 Having 2 empty strings evaluate differently is very unintuitive and
 error-prone, in my opinion.


Very true. Not much we can do about it. For now, the best thing to do is 
always compare arrays to null instead of simply if(arr):

if(arr != null)

Alternatively, but a little more ugly, is to check the length:

if(arr.length)

-Steve
Aug 20 2015
next sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 8/20/15 1:50 PM, Steven Schveighoffer wrote:


 The "truthiness" of an array says it's true ONLY if both the pointer and
 length are 0.


Ugh, *false* only if they are both 0. If either are not zero, then it's 
true.

-Steve
Aug 20 2015
parent reply =?UTF-8?B?Ik3DoXJjaW8=?= Martins" <marcioapm gmail.com> writes:
On Thursday, 20 August 2015 at 18:04:00 UTC, Steven Schveighoffer 
wrote:

 On 8/20/15 1:50 PM, Steven Schveighoffer wrote:


 The "truthiness" of an array says it's true ONLY if both the 
 pointer and
 length are 0.


 Ugh, *false* only if they are both 0. If either are not zero, 
 then it's true.

 -Steve


In other words, it's true when the pointer is not null. i.e. in 
the context of boolean evaluation, it has the semantics of 
string.ptr

It's just making the concept of an empty array a grey cloud.

Consider this:

string a = "";
string b;
	
writeln(a ? "a" : "null");
writeln(b ? "b" : "null");
writeln(a.idup ? "adup" : "null");
writeln(b.idup ? "bdup" : "null");

Output:
a
null
null
null


What?
Aug 20 2015
parent reply =?UTF-8?B?Ik3DoXJjaW8=?= Martins" <marcioapm gmail.com> writes:
On Thursday, 20 August 2015 at 18:42:56 UTC, Márcio Martins wrote:

 On Thursday, 20 August 2015 at 18:04:00 UTC, Steven 
 Schveighoffer wrote:

 On 8/20/15 1:50 PM, Steven Schveighoffer wrote:


 The "truthiness" of an array says it's true ONLY if both the 
 pointer and
 length are 0.


 Ugh, *false* only if they are both 0. If either are not zero, 
 then it's true.

 -Steve


 In other words, it's true when the pointer is not null. i.e. in 
 the context of boolean evaluation, it has the semantics of 
 string.ptr

 It's just making the concept of an empty array a grey cloud.

 Consider this:

 string a = "";
 string b;
 	
 writeln(a ? "a" : "null");
 writeln(b ? "b" : "null");
 writeln(a.idup ? "adup" : "null");
 writeln(b.idup ? "bdup" : "null");

 Output:
 a
 null
 null
 null


 What?


Also, consider this:

writeln(a ? true : false);
writeln(a && a.idup);

Output:
true
false

What?

Should we consider this weird semantics and live with it, as 
there is nothing we can do, or is it a bug in idup()?
Aug 20 2015
parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 8/20/15 3:04 PM, "=?UTF-8?B?Ik3DoXJjaW8=?= Martins\" 
<marcioapm gmail.com>\"" wrote:

 On Thursday, 20 August 2015 at 18:42:56 UTC, Márcio Martins wrote:

 On Thursday, 20 August 2015 at 18:04:00 UTC, Steven Schveighoffer wrote:

 On 8/20/15 1:50 PM, Steven Schveighoffer wrote:


 The "truthiness" of an array says it's true ONLY if both the pointer
 and
 length are 0.


 Ugh, *false* only if they are both 0. If either are not zero, then
 it's true.

 -Steve


 In other words, it's true when the pointer is not null. i.e. in the
 context of boolean evaluation, it has the semantics of string.ptr




Pragmatically speaking, yes. Technically, both are compared, but there 
are very very few cases of the array having null pointer and non-zero 
length.


 It's just making the concept of an empty array a grey cloud.

 Consider this:

 string a = "";
 string b;

 writeln(a ? "a" : "null");
 writeln(b ? "b" : "null");
 writeln(a.idup ? "adup" : "null");
 writeln(b.idup ? "bdup" : "null");

 Output:
 a
 null
 null
 null


 What?




Yep. Just don't use the truthiness of arrays (including strings) and you 
will be ok. Use a.length ? "a" : "null" instead (e.g.).

I haven't used an array as a boolean in years because of this issue, I 
always specify whether I want pointer or length checked.


 Also, consider this:

 writeln(a ? true : false);
 writeln(a && a.idup);

 Output:
 true
 false

 What?


Yep :)


 Should we consider this weird semantics and live with it, as there is
 nothing we can do, or is it a bug in idup()?


Not a bug, idup should not consume a heap block to hold 0 elements, 
returning null is correct. Again, the issue is not idup, but the 
consideration of what the truth value of the array is.

-Steve
Aug 20 2015
prev sibling next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Thu, Aug 20, 2015 at 01:50:11PM -0400, Steven Schveighoffer via
Digitalmars-d wrote:
[...]

 The main reason why it caused issues is this nice idiom:
 
 if(auto arr = someFunction())
 {
    // use arr
 }
 
 This would HAVE to be split out to two statements, and the arr variable
 would be scoped outside of the if statement.


[...]

I wish the language would accept:

	if ((auto arr = someFunction()) !is null)
	{
		...
	}

But IIRC, auto cannot be used except at the top level expression.


T

-- 
Windows 95 was a joke, and Windows 98 was the punchline.
Aug 20 2015
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 08/20/2015 08:05 PM, H. S. Teoh via Digitalmars-d wrote:

 On Thu, Aug 20, 2015 at 01:50:11PM -0400, Steven Schveighoffer via
Digitalmars-d wrote:
 [...]

 The main reason why it caused issues is this nice idiom:

 if(auto arr = someFunction())
 {
     // use arr
 }

 This would HAVE to be split out to two statements, and the arr variable
 would be scoped outside of the if statement.


 [...]

 I wish the language would accept:

 	if ((auto arr = someFunction()) !is null)
 	{
 		...
 	}

 But IIRC, auto cannot be used except at the top level expression.
...


You want !=, not !is.
Aug 20 2015
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 8/20/15 2:49 PM, Timon Gehr wrote:

 On 08/20/2015 08:05 PM, H. S. Teoh via Digitalmars-d wrote:

 On Thu, Aug 20, 2015 at 01:50:11PM -0400, Steven Schveighoffer via
 Digitalmars-d wrote:
 [...]

 The main reason why it caused issues is this nice idiom:

 if(auto arr = someFunction())
 {
     // use arr
 }

 This would HAVE to be split out to two statements, and the arr variable
 would be scoped outside of the if statement.


 [...]

 I wish the language would accept:

     if ((auto arr = someFunction()) !is null)
     {
         ...
     }

 But IIRC, auto cannot be used except at the top level expression.
 ...


 You want !=, not !is.


Current behavior of if(auto arr = someFunction()) is to compare both 
pointer and length to 0, i.e. !is null.

His point is that if we could get rid of if(arr), then there would at 
least be a way to update existing (correct) code that doesn't involve 
refactoring if the given syntax was accepted.

This also would be acceptable (since not much code ever creates arrays 
with null pointer but non-zero length):

if((auto arr = someFunction()).ptr)

-Steve
Aug 20 2015
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 08/20/2015 09:08 PM, Steven Schveighoffer wrote:

 On 8/20/15 2:49 PM, Timon Gehr wrote:

 On 08/20/2015 08:05 PM, H. S. Teoh via Digitalmars-d wrote:

 On Thu, Aug 20, 2015 at 01:50:11PM -0400, Steven Schveighoffer via
 Digitalmars-d wrote:
 [...]

 The main reason why it caused issues is this nice idiom:

 if(auto arr = someFunction())
 {
     // use arr
 }

 This would HAVE to be split out to two statements, and the arr variable
 would be scoped outside of the if statement.


 [...]

 I wish the language would accept:

     if ((auto arr = someFunction()) !is null)
     {
         ...
     }

 But IIRC, auto cannot be used except at the top level expression.
 ...


 You want !=, not !is.


 Current behavior of if(auto arr = someFunction()) is to compare both
 pointer and length to 0, i.e. !is null.
 ...


I know, and it's horrible.


 His point is that if we could get rid of if(arr), then there would at
 least be a way to update existing (correct) code that doesn't involve
 refactoring if the given syntax was accepted.
 ...


Fair enough.


 This also would be acceptable (since not much code ever creates arrays
 with null pointer but non-zero length):

 if((auto arr = someFunction()).ptr)
...


It would certainly be handy, also for other usages.
Aug 20 2015
prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 08/20/2015 07:50 PM, Steven Schveighoffer wrote:

 Very true. Not much we can do about it. For now, the best thing to do is
 always compare arrays to null instead of simply if(arr):

 if(arr != null)

 Alternatively, but a little more ugly, is to check the length:

 if(arr.length)


Isn't the best way to compare to []?

if(arr!=[])

I think comparing to null is needlessly confusing.
Aug 20 2015
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 8/20/15 2:43 PM, Timon Gehr wrote:

 On 08/20/2015 07:50 PM, Steven Schveighoffer wrote:

 Very true. Not much we can do about it. For now, the best thing to do is
 always compare arrays to null instead of simply if(arr):

 if(arr != null)

 Alternatively, but a little more ugly, is to check the length:

 if(arr.length)


 Isn't the best way to compare to []?

 if(arr!=[])

 I think comparing to null is needlessly confusing.


Same thing. [] is null.

-Steve
Aug 20 2015
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 08/20/2015 09:08 PM, Steven Schveighoffer wrote:

 On 8/20/15 2:43 PM, Timon Gehr wrote:

 On 08/20/2015 07:50 PM, Steven Schveighoffer wrote:

 Very true. Not much we can do about it. For now, the best thing to do is
 always compare arrays to null instead of simply if(arr):

 if(arr != null)

 Alternatively, but a little more ugly, is to check the length:

 if(arr.length)


 Isn't the best way to compare to []?

 if(arr!=[])

 I think comparing to null is needlessly confusing.


 Same thing. [] is null.

 -Steve


Sure. I still consider arr!=[] cleaner style. YMMV.
Aug 20 2015
prev sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, 20 August 2015 at 17:50:11 UTC, Steven Schveighoffer 
wrote:

 if(arr != null)


Definitely don't do that. IMHO, "== null and "!= null" should be 
illegal. If you really want to check for null, then you need to 
use "is null" or "!is null", whereas if you want to check that an 
array is empty, check its length or call empty. By using "== 
null" or "!= null", you tend to give the false impression that 
you're checking whether the object or array is null - which is 
not what you're actually doing.

- Jonathan M Davis
Aug 20 2015
next sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 8/20/15 3:41 PM, Jonathan M Davis wrote:

 On Thursday, 20 August 2015 at 17:50:11 UTC, Steven Schveighoffer wrote:

 if(arr != null)


 Definitely don't do that. IMHO, "== null and "!= null" should be
 illegal. If you really want to check for null, then you need to use "is
 null" or "!is null", whereas if you want to check that an array is
 empty, check its length or call empty. By using "== null" or "!= null",
 you tend to give the false impression that you're checking whether the
 object or array is null - which is not what you're actually doing.


On the contrary, checking if it's equal to null checks to see if it has 
the same elements as null. That's exactly what I would want.

If I want to check the pointer, I check arr.ptr != null.

I will note, I tend to have relatively no problem avoiding the 
conflation between null pointers and null arrays. That may not be true 
for most people, but I see them as two different things.

-Steve
Aug 20 2015
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 08/20/2015 09:54 PM, Steven Schveighoffer wrote:

 On 8/20/15 3:41 PM, Jonathan M Davis wrote:

 On Thursday, 20 August 2015 at 17:50:11 UTC, Steven Schveighoffer wrote:

 if(arr != null)


 Definitely don't do that. IMHO, "== null and "!= null" should be
 illegal. If you really want to check for null, then you need to use "is
 null" or "!is null", whereas if you want to check that an array is
 empty, check its length or call empty. By using "== null" or "!= null",
 you tend to give the false impression that you're checking whether the
 object or array is null - which is not what you're actually doing.


 On the contrary, checking if it's equal to null checks to see if it has
 the same elements as null. That's exactly what I would want.
 ...


It's about the /impression/, not about what it's actually doing. It 
clearly does the right thing.


 If I want to check the pointer, I check arr.ptr != null.

 I will note, I tend to have relatively no problem avoiding the
 conflation between null pointers and null arrays. That may not be true
 for most people, but I see them as two different things.

 -Steve


Sure, this is the same for me, but [] may be less confusing than null 
for most readers of the code and it's fewer keystrokes too.
Aug 20 2015
prev sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, 20 August 2015 at 19:54:22 UTC, Steven Schveighoffer 
wrote:

 On 8/20/15 3:41 PM, Jonathan M Davis wrote:

 On Thursday, 20 August 2015 at 17:50:11 UTC, Steven 
 Schveighoffer wrote:

 if(arr != null)


 Definitely don't do that. IMHO, "== null and "!= null" should 
 be
 illegal. If you really want to check for null, then you need 
 to use "is
 null" or "!is null", whereas if you want to check that an 
 array is
 empty, check its length or call empty. By using "== null" or 
 "!= null",
 you tend to give the false impression that you're checking 
 whether the
 object or array is null - which is not what you're actually 
 doing.


 On the contrary, checking if it's equal to null checks to see 
 if it has the same elements as null. That's exactly what I 
 would want.


And why would you want that? The length is meaningless if the 
pointer is null. It shouldn't even be possible for the length to 
be anything other than zero if the pointer is null.

- Jonathan M Davis
Aug 20 2015
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 08/20/2015 10:38 PM, Jonathan M Davis wrote:

 On Thursday, 20 August 2015 at 19:54:22 UTC, Steven Schveighoffer wrote:

 On 8/20/15 3:41 PM, Jonathan M Davis wrote:

 On Thursday, 20 August 2015 at 17:50:11 UTC, Steven Schveighoffer wrote:

 if(arr != null)


 Definitely don't do that. IMHO, "== null and "!= null" should be
 illegal. If you really want to check for null, then you need to use "is
 null" or "!is null", whereas if you want to check that an array is
 empty, check its length or call empty. By using "== null" or "!= null",
 you tend to give the false impression that you're checking whether the
 object or array is null - which is not what you're actually doing.


 On the contrary, checking if it's equal to null checks to see if it
 has the same elements as null. That's exactly what I would want.


 And why would you want that?


Because his goal is to check whether the array is empty or not, and 
comparing to null is one effective way to do it.


 The length is meaningless if the pointer is
 null. It shouldn't even be possible for the length to be anything other
 than zero if the pointer is null.

 - Jonathan M Davis
Aug 20 2015
prev sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 8/20/15 4:38 PM, Jonathan M Davis wrote:

 On Thursday, 20 August 2015 at 19:54:22 UTC, Steven Schveighoffer wrote:

 On 8/20/15 3:41 PM, Jonathan M Davis wrote:

 On Thursday, 20 August 2015 at 17:50:11 UTC, Steven Schveighoffer wrote:

 if(arr != null)


 Definitely don't do that. IMHO, "== null and "!= null" should be
 illegal. If you really want to check for null, then you need to use "is
 null" or "!is null", whereas if you want to check that an array is
 empty, check its length or call empty. By using "== null" or "!= null",
 you tend to give the false impression that you're checking whether the
 object or array is null - which is not what you're actually doing.


 On the contrary, checking if it's equal to null checks to see if it
 has the same elements as null. That's exactly what I would want.


 And why would you want that? The length is meaningless if the pointer is
 null. It shouldn't even be possible for the length to be anything other
 than zero if the pointer is null.


This makes me think you misunderstand what I am doing.

-Steve
Aug 20 2015
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 08/20/2015 10:43 PM, Steven Schveighoffer wrote:

 On 8/20/15 4:38 PM, Jonathan M Davis wrote:

 On Thursday, 20 August 2015 at 19:54:22 UTC, Steven Schveighoffer wrote:

 On 8/20/15 3:41 PM, Jonathan M Davis wrote:

 On Thursday, 20 August 2015 at 17:50:11 UTC, Steven Schveighoffer
 wrote:

 if(arr != null)


 Definitely don't do that. IMHO, "== null and "!= null" should be
 illegal. If you really want to check for null, then you need to use "is
 null" or "!is null", whereas if you want to check that an array is
 empty, check its length or call empty. By using "== null" or "!= null",
 you tend to give the false impression that you're checking whether the
 object or array is null - which is not what you're actually doing.


 On the contrary, checking if it's equal to null checks to see if it
 has the same elements as null. That's exactly what I would want.


 And why would you want that? The length is meaningless if the pointer is
 null. It shouldn't even be possible for the length to be anything other
 than zero if the pointer is null.


 This makes me think you misunderstand what I am doing.

 -Steve


Which was my original point. :o)
Aug 20 2015
parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 8/20/15 4:45 PM, Timon Gehr wrote:

 On 08/20/2015 10:43 PM, Steven Schveighoffer wrote:

 On 8/20/15 4:38 PM, Jonathan M Davis wrote:

 And why would you want that? The length is meaningless if the pointer is
 null. It shouldn't even be possible for the length to be anything other
 than zero if the pointer is null.


 This makes me think you misunderstand what I am doing.


 Which was my original point. :o)


touche ;)

-Steve
Aug 20 2015
prev sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, 20 August 2015 at 20:43:39 UTC, Steven Schveighoffer 
wrote:

 This makes me think you misunderstand what I am doing.


If you care about whether an array is empty, you check whether 
its length is 0 or you call empty (which checks whether the 
length is 0). If you care about whether the array is null, you 
use "is null". I don't understand what else you could possibly be 
doing. "!= null" is just going to end up being equivalent to 
checking whether the length is 0, because the elements won't be 
compared if the length is 0, but it gives the false impression 
that you're checking whether the array is null - hence why 
checking != null is a bad idea. What am I missing here?

- Jonathan M Davis
Aug 20 2015
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 8/20/15 11:15 PM, Jonathan M Davis wrote:

 On Thursday, 20 August 2015 at 20:43:39 UTC, Steven Schveighoffer wrote:

 This makes me think you misunderstand what I am doing.


 If you care about whether an array is empty, you check whether its
 length is 0 or you call empty (which checks whether the length is 0). If
 you care about whether the array is null, you use "is null". I don't
 understand what else you could possibly be doing. "!= null" is just
 going to end up being equivalent to checking whether the length is 0,
 because the elements won't be compared if the length is 0, but it gives
 the false impression that you're checking whether the array is null -
 hence why checking != null is a bad idea. What am I missing here?


You're missing that null is not a pointer in this context, it's an empty 
array. So checking whether the array is null (i.e. empty) *is* what I'm 
doing, and it makes perfect sense to me. The false impression is not one 
of my doing. I can't help your C-based prejudices ;)

Timon is probably right that comparing the array to [] is less confusing 
to others.

-Steve
Aug 21 2015
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 08/21/2015 12:50 PM, Steven Schveighoffer wrote:

 So checking whether the array is null (i.e. empty) *is* what I'm doing,


Nah, you're checking whether it /equals/ null. :-)
Aug 21 2015
prev sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, 21 August 2015 at 10:50:40 UTC, Steven Schveighoffer 
wrote:

 On 8/20/15 11:15 PM, Jonathan M Davis wrote:

 On Thursday, 20 August 2015 at 20:43:39 UTC, Steven 
 Schveighoffer wrote:

 This makes me think you misunderstand what I am doing.


 If you care about whether an array is empty, you check whether 
 its
 length is 0 or you call empty (which checks whether the length 
 is 0). If
 you care about whether the array is null, you use "is null". I 
 don't
 understand what else you could possibly be doing. "!= null" is 
 just
 going to end up being equivalent to checking whether the 
 length is 0,
 because the elements won't be compared if the length is 0, but 
 it gives
 the false impression that you're checking whether the array is 
 null -
 hence why checking != null is a bad idea. What am I missing 
 here?


 You're missing that null is not a pointer in this context, it's 
 an empty array. So checking whether the array is null (i.e. 
 empty) *is* what I'm doing, and it makes perfect sense to me. 
 The false impression is not one of my doing. I can't help your 
 C-based prejudices ;)


I know full-well that that's what you're doing, but that's not 
what your average programmer is going to expect. Anyone not 
intimately familiar with the ins and outs of D's arrays - or even 
a D programmer who's not paying really close attention - is 
likely to think that arr != null is checking whether the array is 
null - not whether the array is empty. And if I see code like 
that, I'm going to assume that the programmer who wrote the code 
really wanted was !is null but either made a mistake or didn't 
understand the difference between !is and != in this context.

Honestly, I think that writing code that uses != null is just as 
error-prone as using arrays in conditions directly. Certainly, 
it's just as confusing to many folks. Yes, it can work, but I 
think that it should be avoided, because it's often going to be 
misinterpreted by those reading the code, and anyone who reads 
the code who does understand the difference between is/!is and 
==/!= is not going to know whether the person who wrote the code 
understood the difference and used == or != on purpose or whether 
they screwed up and didn't use is or !is like they should have.

I would love to see == null and != null be illegal just as much 
as I think that it would be great to make it illegal to use 
arrays in conditions. It's the same problem.

- Jonathan M Davis
Aug 21 2015
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 8/21/15 10:12 AM, Jonathan M Davis wrote:


 I know full-well that that's what you're doing, but that's not what your
 average programmer is going to expect. Anyone not intimately familiar
 with the ins and outs of D's arrays - or even a D programmer who's not
 paying really close attention - is likely to think that arr != null is
 checking whether the array is null - not whether the array is empty. And
 if I see code like that, I'm going to assume that the programmer who
 wrote the code really wanted was !is null but either made a mistake or
 didn't understand the difference between !is and != in this context.


This is a very bad assumption. null is just a name for a pre-defined 
empty array, perfectly legal to compare with.

Whenever I see "arr is ...", I would consider that to likely be a 
mistake warranting further investigation. Because an array is synonymous 
with its elements, not it's pointer. There obviously are cases where the 
pointer value is important, but very very rarely do you care that an 
array's pointer *and* it's length are identical. != does not warrant the 
same scrutiny, because it doesn't care about the pointer value.

-Steve
Aug 21 2015
parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, 21 August 2015 at 14:34:49 UTC, Steven Schveighoffer 
wrote:

 On 8/21/15 10:12 AM, Jonathan M Davis wrote:


 I know full-well that that's what you're doing, but that's not 
 what your
 average programmer is going to expect. Anyone not intimately 
 familiar
 with the ins and outs of D's arrays - or even a D programmer 
 who's not
 paying really close attention - is likely to think that arr != 
 null is
 checking whether the array is null - not whether the array is 
 empty. And
 if I see code like that, I'm going to assume that the 
 programmer who
 wrote the code really wanted was !is null but either made a 
 mistake or
 didn't understand the difference between !is and != in this 
 context.


 This is a very bad assumption. null is just a name for a 
 pre-defined empty array, perfectly legal to compare with.

 Whenever I see "arr is ...", I would consider that to likely be 
 a mistake warranting further investigation. Because an array is 
 synonymous with its elements, not it's pointer. There obviously 
 are cases where the pointer value is important, but very very 
 rarely do you care that an array's pointer *and* it's length 
 are identical. != does not warrant the same scrutiny, because 
 it doesn't care about the pointer value.


Yes, but null is pretty much synonymous with pointers. Almost 
anyone who sees null is going to be thinking pointers. The way 
that we treat null with arrays is just plain bizarre. It works, 
but it's not what anyone coming to the language expects, and I 
think that explicitly using null to mean anything other than null 
is just plain error-prone. Yes, using ==/!= to compare an array 
with null is going to check for empty rather than check the 
pointer, which is consistent with how it's going to work when 
comparing with another array which is null, but how many 
programmers are really going to look at arr == null and think 
that it's checking whether the array is empty? If they have 
enough experience in D _and_ they're paying enough attention, 
then they'll understand what's going on and catch it, but there's 
no reason to introduce that level of confusion in the first 
place. IMHO, it's far better to just be explicit about it and do 
arr.empty - or arr.length != 0 if you don't want to pull in 
std.array. I see zero benefit in doing arr == null and only an 
invitation to confuse people - be it someone who doesn't 
understand all of the intricacies of D's arrays or a developer 
that's working too late. Using arr.empty just eliminates all of 
that confusion and makes the code clear.

- Jonathan M Davis
Aug 21 2015
prev sibling parent reply "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Thursday, 20 August 2015 at 19:41:44 UTC, Jonathan M Davis 
wrote:

 On Thursday, 20 August 2015 at 17:50:11 UTC, Steven 
 Schveighoffer wrote:

 if(arr != null)


 Definitely don't do that. IMHO, "== null and "!= null" should 
 be illegal. If you really want to check for null, then you need 
 to use "is null" or "!is null", whereas if you want to check 
 that an array is empty, check its length or call empty. By 
 using "== null" or "!= null", you tend to give the false 
 impression that you're checking whether the object or array is 
 null - which is not what you're actually doing.


I disagree. `is null` is the one that should be illegal. `is` is 
supposed to do a bitwise comparison, but `null` is usually just a 
pointer/reference, while a slice consists of both a reference and 
a length. Which of those are compared?
Aug 21 2015
next sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 8/21/15 7:34 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net>" 
wrote:

 On Thursday, 20 August 2015 at 19:41:44 UTC, Jonathan M Davis wrote:

 On Thursday, 20 August 2015 at 17:50:11 UTC, Steven Schveighoffer wrote:

 if(arr != null)


 Definitely don't do that. IMHO, "== null and "!= null" should be
 illegal. If you really want to check for null, then you need to use
 "is null" or "!is null", whereas if you want to check that an array is
 empty, check its length or call empty. By using "== null" or "!=
 null", you tend to give the false impression that you're checking
 whether the object or array is null - which is not what you're
 actually doing.


 I disagree. `is null` is the one that should be illegal. `is` is
 supposed to do a bitwise comparison, but `null` is usually just a
 pointer/reference, while a slice consists of both a reference and a
 length. Which of those are compared?


Both. null in this context is actually an array (with null pointer and 
zero length).

null is technically a no-type placeholder (defaulting to void * without 
context). In different contexts it means different things.

arr is null -> both pointer and length are 0
arr == null -> arr contains the same elements that null contains.
arr.ptr == null -> arr contains a null pointer (length could technically 
be non-zero).

-Steve
Aug 21 2015
next sibling parent "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Friday, 21 August 2015 at 11:43:11 UTC, Steven Schveighoffer 
wrote:

 On 8/21/15 7:34 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= 
 <schuetzm gmx.net>" wrote:

 I disagree. `is null` is the one that should be illegal. `is` 
 is
 supposed to do a bitwise comparison, but `null` is usually 
 just a
 pointer/reference, while a slice consists of both a reference 
 and a
 length. Which of those are compared?


 Both. null in this context is actually an array (with null 
 pointer and zero length).

 null is technically a no-type placeholder (defaulting to void * 
 without context). In different contexts it means different 
 things.

 arr is null -> both pointer and length are 0
 arr == null -> arr contains the same elements that null 
 contains.
 arr.ptr == null -> arr contains a null pointer (length could 
 technically be non-zero).


Thank for clarifying, I suspected that. Still not a good idea to 
use, IMO.
Aug 21 2015
prev sibling next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 08/21/2015 01:43 PM, Steven Schveighoffer wrote:

 null is technically a no-type placeholder (defaulting to void * without
 context).


It now defaults to typeof(null), which is a distinct type from void*.
The same is confusingly not true for [] though, which still defaults to 
void[].
Aug 21 2015
prev sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, 21 August 2015 at 11:43:11 UTC, Steven Schveighoffer 
wrote:

 On 8/21/15 7:34 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= 
 <schuetzm gmx.net>" wrote:

 On Thursday, 20 August 2015 at 19:41:44 UTC, Jonathan M Davis 
 wrote:

 On Thursday, 20 August 2015 at 17:50:11 UTC, Steven 
 Schveighoffer wrote:

 if(arr != null)


 Definitely don't do that. IMHO, "== null and "!= null" should 
 be
 illegal. If you really want to check for null, then you need 
 to use
 "is null" or "!is null", whereas if you want to check that an 
 array is
 empty, check its length or call empty. By using "== null" or 
 "!=
 null", you tend to give the false impression that you're 
 checking
 whether the object or array is null - which is not what you're
 actually doing.


 I disagree. `is null` is the one that should be illegal. `is` 
 is
 supposed to do a bitwise comparison, but `null` is usually 
 just a
 pointer/reference, while a slice consists of both a reference 
 and a
 length. Which of those are compared?


 Both. null in this context is actually an array (with null 
 pointer and zero length).

 null is technically a no-type placeholder (defaulting to void * 
 without context). In different contexts it means different 
 things.

 arr is null -> both pointer and length are 0
 arr == null -> arr contains the same elements that null 
 contains.
 arr.ptr == null -> arr contains a null pointer (length could 
 technically be non-zero).


For all intents and purposes

arr is null

is equivalent to

arr.ptr is null

ptr is a read-only property, so you can only set the ptr to null 
if you set the array to null by assigning it null explicitly or 
by assigning it an array which is null. "is null" is how you're 
supposed to check pointers and references for null - explicitly 
comparing a class object to null with == is actually illegal - 
and I see no reason that arrays should be any different.

Regardless, using "is null" actually checks for whether an array 
is null, whereas "== null" checks whether it's empty and doesn't 
care about the ptr value - which is _not_ what most programmers 
are going to expect when you compare something against null.

- Jonathan M Davis
Aug 21 2015
prev sibling next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 08/21/2015 01:34 PM, "Marc =?UTF-8?B?U2Now7x0eiI=?= 
<schuetzm gmx.net>" wrote:

 On Thursday, 20 August 2015 at 19:41:44 UTC, Jonathan M Davis wrote:

 On Thursday, 20 August 2015 at 17:50:11 UTC, Steven Schveighoffer wrote:

 if(arr != null)


 Definitely don't do that. IMHO, "== null and "!= null" should be
 illegal. If you really want to check for null, then you need to use
 "is null" or "!is null", whereas if you want to check that an array is
 empty, check its length or call empty. By using "== null" or "!=
 null", you tend to give the false impression that you're checking
 whether the object or array is null - which is not what you're
 actually doing.


 I disagree. `is null` is the one that should be illegal. `is` is
 supposed to do a bitwise comparison,


If 'is null' is disallowed, what's the point of allowing '== null'?


 but `null` is usually just a
 pointer/reference,  while a slice consists of both a reference and a
 length.


There's a 'null slice'. Both pointer and length are null. It's what the 
implicit conversion from 'typeof(null)' yields.


 Which of those are compared?


Both. You explained it above.
Aug 21 2015
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Friday, 21 August 2015 at 11:34:42 UTC, Marc Schütz wrote:

 On Thursday, 20 August 2015 at 19:41:44 UTC, Jonathan M Davis 
 wrote:

 On Thursday, 20 August 2015 at 17:50:11 UTC, Steven 
 Schveighoffer wrote:

 if(arr != null)


 Definitely don't do that. IMHO, "== null and "!= null" should 
 be illegal. If you really want to check for null, then you 
 need to use "is null" or "!is null", whereas if you want to 
 check that an array is empty, check its length or call empty. 
 By using "== null" or "!= null", you tend to give the false 
 impression that you're checking whether the object or array is 
 null - which is not what you're actually doing.


 I disagree. `is null` is the one that should be illegal. `is` 
 is supposed to do a bitwise comparison, but `null` is usually 
 just a pointer/reference, while a slice consists of both a 
 reference and a length. Which of those are compared?


is, as its name says, is an identity check. It check that 2 thing 
ARE the same thing.

==, on the other hand, is a value check. It check if 2 thing have 
the same value, regardless if they are the same or not.
Aug 21 2015
prev sibling parent "Kagamin" <spam here.lot> writes:
On Friday, 21 August 2015 at 11:34:42 UTC, Marc Schütz wrote:

 On Thursday, 20 August 2015 at 19:41:44 UTC, Jonathan M Davis 
 wrote:

 On Thursday, 20 August 2015 at 17:50:11 UTC, Steven 
 Schveighoffer wrote:

 if(arr != null)


 Definitely don't do that. IMHO, "== null and "!= null" should 
 be illegal. If you really want to check for null, then you 
 need to use "is null" or "!is null", whereas if you want to 
 check that an array is empty, check its length or call empty. 
 By using "== null" or "!= null", you tend to give the false 
 impression that you're checking whether the object or array is 
 null - which is not what you're actually doing.


 I disagree. `is null` is the one that should be illegal. `is` 
 is supposed to do a bitwise comparison, but `null` is usually 
 just a pointer/reference, while a slice consists of both a 
 reference and a length. Which of those are compared?


No ambiguity there: D doesn't allow comparison of array with 
pointer.
Aug 24 2015
prev sibling next sibling parent reply "David Nadlinger" <code klickverbot.at> writes:
On Thursday, 20 August 2015 at 16:45:18 UTC, Márcio Martins wrote:

 Having 2 empty strings evaluate differently is very unintuitive 
 and error-prone, in my opinion.


It's even worse: http://dpaste.dzfl.pl/ba3376feca8e

The arrays are equal, but their Boolean value is not.

I don't get how Andrei can reconcile this with his "D avoids 
unforced errors" stance.

  — David
Aug 20 2015
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 08/20/2015 10:26 PM, David Nadlinger wrote:

 On Thursday, 20 August 2015 at 16:45:18 UTC, Márcio Martins wrote:

 Having 2 empty strings evaluate differently is very unintuitive and
 error-prone, in my opinion.


 It's even worse: http://dpaste.dzfl.pl/ba3376feca8e

 The arrays are equal, but their Boolean value is not.

 I don't get how Andrei can reconcile this with his "D avoids unforced
 errors" stance.

   — David


By denying that it is an error and by playing down its significance, IIRC.
Same about [] is null, [1][1..1] is null, but {auto a=[1]; return 
a[1..1];}() !is null and related cases.
Aug 20 2015
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 20 August 2015 at 20:39:01 UTC, Timon Gehr wrote:

 On 08/20/2015 10:26 PM, David Nadlinger wrote:

 On Thursday, 20 August 2015 at 16:45:18 UTC, Márcio Martins 
 wrote:

 Having 2 empty strings evaluate differently is very 
 unintuitive and
 error-prone, in my opinion.


 It's even worse: http://dpaste.dzfl.pl/ba3376feca8e

 The arrays are equal, but their Boolean value is not.

 I don't get how Andrei can reconcile this with his "D avoids 
 unforced
 errors" stance.

   — David


 By denying that it is an error and by playing down its 
 significance, IIRC.
 Same about [] is null, [1][1..1] is null, but {auto a=[1]; 
 return a[1..1];}() !is null and related cases.


Note that even if you put that asside, D makes the difference 
between equality and identity. null check is an identity check, 
while truthiness is a value check. The semantic is not coherent.
Aug 21 2015
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 08/22/2015 02:04 AM, deadalnix wrote:

 On Thursday, 20 August 2015 at 20:39:01 UTC, Timon Gehr wrote:

 On 08/20/2015 10:26 PM, David Nadlinger wrote:

 On Thursday, 20 August 2015 at 16:45:18 UTC, Márcio Martins wrote:

 Having 2 empty strings evaluate differently is very unintuitive and
 error-prone, in my opinion.


 It's even worse: http://dpaste.dzfl.pl/ba3376feca8e

 The arrays are equal, but their Boolean value is not.

 I don't get how Andrei can reconcile this with his "D avoids unforced
 errors" stance.

   — David


 By denying that it is an error and by playing down its significance,
 IIRC.
 Same about [] is null, [1][1..1] is null, but {auto a=[1]; return
 a[1..1];}() !is null and related cases.


 Note that even if you put that asside, D makes the difference between
 equality and identity. null check is an identity check, while truthiness
 is a value check. The semantic is not coherent.


That's also a good point.
Aug 21 2015
prev sibling parent reply "Kagamin" <spam here.lot> writes:
On Thursday, 20 August 2015 at 20:26:09 UTC, David Nadlinger 
wrote:

 It's even worse: http://dpaste.dzfl.pl/ba3376feca8e

 The arrays are equal, but their Boolean value is not.

 I don't get how Andrei can reconcile this with his "D avoids 
 unforced errors" stance.


The only technical excuse for the bug is code breakage, which can 
be mostly addressed by dfix, but that's yet another problem: 
tools like dfix are shunned for some reason.
Aug 21 2015
parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, 21 August 2015 at 09:14:16 UTC, Kagamin wrote:

 On Thursday, 20 August 2015 at 20:26:09 UTC, David Nadlinger 
 wrote:

 It's even worse: http://dpaste.dzfl.pl/ba3376feca8e

 The arrays are equal, but their Boolean value is not.

 I don't get how Andrei can reconcile this with his "D avoids 
 unforced errors" stance.


 The only technical excuse for the bug is code breakage, which 
 can be mostly addressed by dfix, but that's yet another 
 problem: tools like dfix are shunned for some reason.


I don't think that the use of dfix is shunned. Rather, dfix is 
shunned as a solution, because it requires that you run it. 
Walter gets unhappy about changing compiler flags even if the fix 
to existing code is trivial, because it requires that someone 
change their build scripts. The simply fact that code broke - 
regardless of how easy it is to fix - seems to be enough for 
Walter to think that it's a terrible idea. So, given Walter's 
attitude on that, I don't think that it really matters how good 
dfix is. Even if it were guaranteed to perfectly change all code 
that it was run on to fix whatever broke with a compiler or 
library change, the fact that you had to run it to fix the 
breakage was already too much.

I think that most of us would agree that if a change is desirable 
(assuming that code breakage is not taken into account) that if 
dfix is able to just fix whatever code breakage occurs, then the 
breakage isn't a big deal (at least as long as it's made clear to 
everyone getting the new release what the breakage is and that 
dfix will fix it for them). But Walter definitely does not seem 
to agree with that. Breakage is breakage no matter how easy it is 
to fix. Upon occasion, he will agree that something is worth 
breaking because of some huge benefit that we get from it, but 
that's pretty rare, and most of stuff that folks want to see 
broken to clean up the language definitely doesn't bring enough 
of a benefit for him to agree to it.

- Jonathan M Davis
Aug 21 2015
prev sibling parent "ponce" <contact gam3sfrommars.fr> writes:
On Thursday, 20 August 2015 at 16:45:18 UTC, Márcio Martins wrote:

 Hi!


 string a = "";
 string b;

 writeln(a ? "a" : "null");
 writeln(b ? "b" : "null");


 This program outputs:
 a
 null



 What?

 I suppose this is by design, but are there any plans to 
 deprecate this?


Sounds correct to me.
Aug 23 2015