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.

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.

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

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

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

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.

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?

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.

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.

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.