On 04/10/2015 07:28 PM, Steven Schveighoffer wrote:
>> Also empty should work for AAs.
> 
> How should "abc".front work? Do you want to move unicode decoding of char and wchar arrays into object.d?

We already have unicode decoding in druntime, the old and slow version
though. Wouldn't cost much to move those 2 functions.
Also we now have core.internal for more contrived stuff, works like this.
https://github.com/D-Programming-Language/druntime/blob/master/src/object.di#L697

On Friday, 10 April 2015 at 09:35:44 UTC, John Colvin wrote:
> As others have mentioned, why not make if(arr) be equivalent to if(arr.length)? It seems that's what everyone actually wants when they type it.

Yes, and the worst part of it all, is that it mostly works, so you may miss it when testing.

On Friday, 10 April 2015 at 18:32:39 UTC, Andrei Alexandrescu wrote:
> On 4/10/15 10:28 AM, Steven Schveighoffer wrote:
>> On 4/10/15 11:57 AM, Andrei Alexandrescu wrote:
>>> On 4/10/15 6:26 AM, Meta wrote:
>>>> On Friday, 10 April 2015 at 12:42:47 UTC, Steven Schveighoffer wrote:
>>>>> Plus, adding arr.empty into object is kind of redundant. The only
>>>>> reason we have arr.empty is so that it becomes a range.
>>>>>
>>>>> -Steve
>>>>
>>>> I find it extremely annoying to have to import std.array (or whatever
>>>> the correct module is) just to use .empty, .front and .popFront on
>>>> arrays. IMO they should all be in object.d.
>>>
>>> Yah, I was about to post the same. Range semantics are embedded in the
>>> language enough to warrant this.
>>>
>>> Also empty should work for AAs.
>>
>> How should "abc".front work? Do you want to move unicode decoding of
>> char and wchar arrays into object.d? Serious question, not rhetorical,
>> because I'm not for or against it (except for the notion of changing
>> things for the sake of changing them), I just want to point out what is
>> required.
>
> Should decode. Meaning there's no change of semantics, just where the facility is defined. -- Andrei

Having thought about it more, I think that is why we cannot put the range primitives for slices into object.d. Because that makes it impossible to define the primitives differently, so that no auto-decoding occurs. At the moment, auto-decoding isn't part of the language, it's just written in to the standard library. This would change that.

On 04/11/2015 01:03 PM, w0rp wrote:
> At the moment, auto-decoding isn't part of the language

That won't change anytime soon.

On 4/11/15 4:03 AM, w0rp wrote:
> Having thought about it more, I think that is why we cannot put the
> range primitives for slices into object.d. Because that makes it
> impossible to define the primitives differently, so that no
> auto-decoding occurs. At the moment, auto-decoding isn't part of the
> language, it's just written in to the standard library. This would
> change that.

That's where it should be. -- Andrei

On Friday, April 10, 2015 09:27:55 w0rp via Digitalmars-d wrote:
> I think it's worth changing this.
>
> if (arr)
>
> translating to
>
> if (arr.length == 0)
>
> Is immediately obvious for anyone coming from at least a Python
> background. I have implemented my own hashmaps in a similar way.
> For my maps, the length is stored in the map so it can be
> retrieved in O(1) time, and cast(bool) results in map.length ==
> 0. (This extends also to empty sets.)
>
> If we need a deprecation path, we can do it. We just warn about
> if (arr) for a while, so you are told to use if(arr.length == 0)
> or if (arr.ptr is null) for a while, then we change the behaviour
> in another release.

I agree with the change, because the current behavior is error-prone.
However, I'd just as soon leave if(arr) as illegal so that there's no
confusion over it later. Just because one set of folks think that if(arr) is
clearly equivalant to if(arr.length != 0) doesn't mean another set of folks
will - especially if it's based on what other languages are up to. For
instance, while python folks might think that it would be intuitive if
if(arr) were equivalent to if(arr.length != 0), the C folks would think that
the current behavior of it being equivalent to if(arr is null) would be more
intuitive, since they're used to thinking of arrays as pointers. By simply
forcing folks to be explicit and say if(arr.length != 0) or if(arr is null),
we avoid the problem entirely.

- Jonathan M Davis

On Sunday, 19 April 2015 at 08:05:46 UTC, Jonathan M Davis wrote:
> On Friday, April 10, 2015 09:27:55 w0rp via Digitalmars-d wrote:
>> I think it's worth changing this.
>>
>> if (arr)
>>
>> translating to
>>
>> if (arr.length == 0)
>>
>> Is immediately obvious for anyone coming from at least a Python
>> background. I have implemented my own hashmaps in a similar way.
>> For my maps, the length is stored in the map so it can be
>> retrieved in O(1) time, and cast(bool) results in map.length ==
>> 0. (This extends also to empty sets.)
>>
>> If we need a deprecation path, we can do it. We just warn about
>> if (arr) for a while, so you are told to use if(arr.length == 0)
>> or if (arr.ptr is null) for a while, then we change the behaviour
>> in another release.
>
> I agree with the change, because the current behavior is error-prone.
> However, I'd just as soon leave if(arr) as illegal so that there's no
> confusion over it later. Just because one set of folks think that if(arr) is
> clearly equivalant to if(arr.length != 0) doesn't mean another set of folks
> will - especially if it's based on what other languages are up to. For
> instance, while python folks might think that it would be intuitive if
> if(arr) were equivalent to if(arr.length != 0), the C folks would think that
> the current behavior of it being equivalent to if(arr is null) would be more
> intuitive, since they're used to thinking of arrays as pointers. By simply
> forcing folks to be explicit and say if(arr.length != 0) or if(arr is null),
> we avoid the problem entirely.
>
> - Jonathan M Davis

Unfortunately it also disables this very useful idiom:

if(auto name = getName())

I.e. declaration and conditional in one.

On Sunday, 19 April 2015 at 08:05:46 UTC, Jonathan M Davis wrote:
> the C folks would think that
> the current behavior of it being equivalent to if(arr is null) would be more
> intuitive, since they're used to thinking of arrays as pointers.

Are they used to disregard value types too? I don't see it working in C: http://ideone.com/rzSSlx

On 4/20/15 12:14 PM, Kagamin wrote:
> On Sunday, 19 April 2015 at 08:05:46 UTC, Jonathan M Davis wrote:
>> the C folks would think that
>> the current behavior of it being equivalent to if(arr is null) would
>> be more
>> intuitive, since they're used to thinking of arrays as pointers.
>
> Are they used to disregard value types too? I don't see it working in C:
> http://ideone.com/rzSSlx

Not exactly. Because C arrays are pointers, it does work that way:

void foo(int c[])
{
   if(c) {...} // same as if(c is null)
}

But C doesn't have any other possible piece to check, as the length of the array is not part of the code.

The closest equivalent is C++ vectors, and if(someVector) doesn't work.

-Steve

On Monday, April 20, 2015 16:14:39 Kagamin via Digitalmars-d wrote:
> On Sunday, 19 April 2015 at 08:05:46 UTC, Jonathan M Davis wrote:
> > the C folks would think that
> > the current behavior of it being equivalent to if(arr is null)
> > would be more
> > intuitive, since they're used to thinking of arrays as pointers.
>
> Are they used to disregard value types too? I don't see it working in C: http://ideone.com/rzSSlx

An array in C is a pointer, not a struct. So, the obvious thing for a C programmer when they see

if(arr)

would be to think that it was equivalent to

if(arr != NULL)

or

if(arr != 0)

and _not_ something like

if(arr.length != 0)

particularly since arrays don't even know their length in C. Obviously, if they're dealing with a struct, then it's not the same, and D arrays are technically structs, but regardless, if you're a C/C++ programmer and you're using a struct to hold the length of your array along with its pointer, and you were going to decide what

if(arr)

is going to mean, then checking whether ptr was null or not would be the obvious thing (which _can_ be defined in C++ via an overloaded cast operator, just not in C). As such, being derived from C, D's current behavior is very logical - _far_ more so than checking the array's length. For someone with a C/C++ background, there's no reason whatsoever to expect that it would be checking for length. The problem comes in when you consider that in most other cases, D tries to avoid segfaulting for null arrays, and treats null arrays as empty (e.g. with equality), so checking for null arrays becomes a rare thing to need, and folks from some other languages apparently think that it's normal to expect that

if(arr)

would check for non-empty. So, it arguably becomes too confusing to allow

if(arr)

But given D's C heritage, what it currently does is exactly what I'd expect it to do and is likely what most C/C++ programmers would expect it to do.

- Jonathan M Davis