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

[Regan Heath]

On Fri, 05 Jul 2013 11:39:37 +0100, Dmitry Olshansky  
<dmitry.olsh at gmail.com> wrote:
> 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.

True, but the actual implementation isn't the issue.  The concept of D's  
arrays was to wrap pointers in order to make them safer.  So,  
/conceptually/ an array is a thin wrapper over a pointer.  Concept defines  
semantics, rather than implementation, IMO :)

>> 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.

To my mind wrappers aren't limited in such a way and can add  
functionality, the key to me is that they continue to expose the  
underlying object, which d's arrays do (in various ways).

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/