On Sunday, 19 February 2012 at 03:33:14 UTC, Timon Gehr wrote:
>> That would potentially break code.
>
> It would also potentially fix code.

Well that's the stupidest thing I've read today. Can you point to people using it in the way that you expect? Besides which, that's just about the worst way to fix bugs in code is to change the language's behaviour.

On Sunday, February 19, 2012 04:52:48 Timon Gehr wrote:
> That is true. It is also what worries me. Having cast(bool) evaluate to false for empty arrays is intuitive and has massive precedent in other programming languages.

If we think that the problems solved by it are greater than those caused by it, then the change should be made (and some of your examples make the current behavior look pretty bizarre). But it's all wrapped up in the whole nonsense of how null is handled with arrays, which is broken by design IMHO.

- Jonathan M Davis

On 02/19/2012 04:56 AM, Bernard Helyer wrote:
> On Sunday, 19 February 2012 at 03:33:14 UTC, Timon Gehr wrote:
>>> That would potentially break code.
>>
>> It would also potentially fix code.
>
> Well that's the stupidest thing I've read today. Can you point to people
> using it in the way that you expect? Besides which, that's just about
> the worst way to fix bugs in code is to change the language's behaviour.
>

I was not being entirely serious here... Do you have any opinion about the topic?

On Sunday, February 19, 2012 04:56:13 Bernard Helyer wrote:
> On Sunday, 19 February 2012 at 03:33:14 UTC, Timon Gehr wrote:
> >> That would potentially break code.
> > 
> > It would also potentially fix code.
> 
> Well that's the stupidest thing I've read today. Can you point to people using it in the way that you expect? Besides which, that's just about the worst way to fix bugs in code is to change the language's behaviour.

I've seen pull requests for code where people have done

if(arr)

thinking that it would check for empty. The bizarrities with null == [] cause subtle problems all the time.

Now, whether more people have done

if(arr)

thinking that it checked null or more people have done it thinking that it checked empty, I don't know, but there's no question that some people do it thinking that it checks for empty.

- Jonathan M Davis

On 02/19/2012 05:01 AM, Timon Gehr wrote:
> On 02/19/2012 04:56 AM, Bernard Helyer wrote:
>> On Sunday, 19 February 2012 at 03:33:14 UTC, Timon Gehr wrote:
>>>> That would potentially break code.
>>>
>>> It would also potentially fix code.
>>
>> Well that's the stupidest thing I've read today. Can you point to people
>> using it in the way that you expect? Besides which, that's just about
>> the worst way to fix bugs in code is to change the language's behaviour.
>>
>
> I was not being entirely serious here...

Technically the statement is still true, of course.

On Sunday, 19 February 2012 at 04:01:45 UTC, Timon Gehr wrote:
> On 02/19/2012 04:56 AM, Bernard Helyer wrote:
>> On Sunday, 19 February 2012 at 03:33:14 UTC, Timon Gehr wrote:
>>>> That would potentially break code.
>>>
>>> It would also potentially fix code.
>>
>> Well that's the stupidest thing I've read today. Can you point to people
>> using it in the way that you expect? Besides which, that's just about
>> the worst way to fix bugs in code is to change the language's behaviour.
>>
>
> I was not being entirely serious here... Do you have any opinion about the topic?

I think it's too late to change the behaviour, and it's not too terrible, even if un-ideal.

On 02/19/2012 06:15 AM, Bernard Helyer wrote:
> On Sunday, 19 February 2012 at 04:01:45 UTC, Timon Gehr wrote:
>> On 02/19/2012 04:56 AM, Bernard Helyer wrote:
>>> On Sunday, 19 February 2012 at 03:33:14 UTC, Timon Gehr wrote:
>>>>> That would potentially break code.
>>>>
>>>> It would also potentially fix code.
>>>
>>> Well that's the stupidest thing I've read today. Can you point to people
>>> using it in the way that you expect? Besides which, that's just about
>>> the worst way to fix bugs in code is to change the language's behaviour.
>>>
>>
>> I was not being entirely serious here... Do you have any opinion about
>> the topic?
>
> I think it's too late to change the behaviour,

It is a good time to change the behavior: We are still in a stage where almost every release of the reference compiler breaks some code.

> and it's not too terrible, even if un-ideal.
>

It is completely useless. It should rather be disabled as bearophile suggests and then be re-enabled with the sane semantics after enough time has passed.

I agree, and I doubt it was intentional.

if (arr) should mean if (arr.length && arr.ptr)
But since you can only get (arr.length != 0 && arr.ptr == null) when doing
unsafe things with arrays, I think it's entirely reasonable to use
if (arr) -> if (arr.length)

This is what I expected.

Much like with class references, distinguishing between null and empty is not '=='s job, that is what 'is' is for.

"Timon Gehr" <timon.gehr@gmx.ch> wrote in message news:jhpl6j$2m6c$1@digitalmars.com...
> Why does the following code behave funny?
>
> void main(){
>     string x = " "[1..1];
>     writeln(cast(bool)x); // true
>     char[] y = [' '][1..1];
>     writeln(cast(bool)y); // false
> }
>
> Is there any reason for empty arrays to evaluate to true? This is very bug prone.

Timon Gehr

> Indeed. I have never needed arr == null. Comparing class references to null using '==' is illegal. Probably the same could be done for arrays. Would also increase consistency.

Is this in Bugzilla already?

Bye,
bearophile

On 02/19/2012 01:54 PM, bearophile wrote:
> Timon Gehr
>
>> Indeed. I have never needed arr == null. Comparing class references to
>> null using '==' is illegal. Probably the same could be done for arrays.
>> Would also increase consistency.
>
> Is this in Bugzilla already?
>
> Bye,
> bearophile

I don't think so.