[:] as empty associative array literal, plus warning for null

[Dmitry Olshansky]

05-Jul-2013 13:24, Regan Heath пишет:
> On Fri, 05 Jul 2013 10:13:11 +0100, Dmitry Olshansky
> <dmitry.olsh at gmail.com> wrote:
>
>> 05-Jul-2013 12:55, Regan Heath пишет:
>>> On Thu, 04 Jul 2013 20:15:08 +0100, Dmitry Olshansky
>>> <dmitry.olsh at gmail.com> wrote:
>>>
>>>> 04-Jul-2013 19:00, Regan Heath пишет:
>>>>> In fact, you can generalise further.
>>>>>
>>>>> The meaning of if(x) is "compare the value of x with 0" (in C, C++,
>>>>> .. ).
>>>>>
>>>>> The value of x for a pointer is the address to which it points.
>>>>> The value of x for a class reference is the address of the class to
>>>>> which it refers.
>>>>>
>>>>> If D's arrays are reference types,
>>>>
>>>> They are not. It's a half-reference no wonder it has a bit of
>>>> schizophrenia now and then.
>>>
>>> True.  The struct which contains the ptr and length is actually a value
>>> type.  I think conceptually however we should be thinking of them as
>>> reference types, because.. the array struct is effectively a lightweight
>>> wrapper (adding length) around a reference type (ptr).
>>>
>>>>   then IMO they should exhibit the same
>>>>> behaviour.
>>>>>
>>>>
>>>> The behavior should be the most useful and since arr.length != 0 is
>>>> what 99% of time a programmer wants to check.
>>>
>>> IMO, the behaviour should be consistent.  If you code if (x) then the
>>> compiler will compare 'x' (not a property of x) to 0.  Doing anything
>>> else would be inconsistent and unexpected to anyone from a C background.
>>
>> Then since slices compared to null by your logic means both ptr and
>> length equal 0. Completely broken idea hence I'd simply propose to
>> disable it.
>
> I think I need to clarify.
>
> I am making 3 statements here:
>
> 1. Arrays are a thin wrapper around a reference type (ptr) which add
> safety.

Rather it packs 2 pointers (pair: ptr, ptr+len), modeling the region in 
between.
No matter how we look at it, it doesn't overlap with most of pointer 
operations except for indexing. In my opinion it can't be framed as a 
thin wrapper around _one_ pointer.

> 2. When you have a thin wrapper you should treat operations on the
> wrapper as the wrapped object in the general case.

Continuation of the above stretch.
To be a true wrapper it has to support only the same or subset of 
operations. For instance arrays have slicing operation hence it's more 
then that.

> 3. if (x) should compare x to 0.

This one is consistent.

> Given those statements I have come to the conclusion that if (x) on an
> array should compare x.ptr to 0.

I'd agree if arrays did decay to pointers or integers on demand 
(implicit conversion).

> Which of my statements do you disagree with, and why?
>
> R
>


-- 
Dmitry Olshansky