[:] as empty associative array literal, plus warning for null
dmitry.olsh at gmail.com
Fri Jul 5 03:39:37 PDT 2013
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
>>>> 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
Rather it packs 2 pointers (pair: ptr, ptr+len), modeling the region in
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
> 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
> Which of my statements do you disagree with, and why?
More information about the Digitalmars-d