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.
Why not use C/C++/C# initializer syntax? Technically it's a 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