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

[Timon Gehr]

On 07/04/2013 07:32 PM, Andrei Alexandrescu wrote:
> On 7/4/13 9:51 AM, Timon Gehr wrote:
>> On 07/04/2013 05:51 PM, Andrei Alexandrescu wrote:
>>> On 7/4/13 8:27 AM, Timon Gehr wrote:
>>>> On 07/04/2013 04:35 PM, Andrei Alexandrescu wrote:
>>>>> On 7/4/13 6:32 AM, Steven Schveighoffer wrote:
>>>>>> I would not be opposed to a pull request that made [] be non-null, as
>>>>>> long as it doesn't allocate.
>>>>>
>>>>> What would be the benefits?
>>>>>
>>>>> Andrei
>>>>
>>>> - Additional sentinel values at basically no cost.
>>>
>>> OK, an "extra null". These can occasionally useful.
>>>
>>>> - No accidental flawed relying on empty array is null or empty array
>>>> !is
>>>> null.
>>>> (i.e. less nondeterminism.)
>>>
>>> But null arrays stay, so this doesn't help with that. It may actually
>>> add confusion.
>>>
>>
>> It is more likely that 'if(array !is null) { }' is valid under the
>> stronger semantics than under the old ones. This removes a potentially
>> bug-prone construct, since it is easy to fall into the trap of expecting
>> that different syntax denotes a different construct.
>
> Why? Maybe someone returned [] thinking it will be a null array.

Maybe someone returned [] thinking it won't be null.

int[] foo(int[] x){
     if(a) return [1,2,3];          // not null
     if(b) return [1,2];            // not null
     if(c) return [1];              // not null
     if(e) return [];               // _
     if(x !is null) return x[0..0]; // not null
     return null;                   // null
}

void bar(){
     // ...
     auto y=foo(x);
     // ...
}


> I don't see how adding an obscure "whoa, this is an empty array, but
> surprisingly, it's not null!" marks an increase in clarity.
>

Please justify "obscure".

>>>> - One  thing less to discuss (this has come up before.)
>>>
>>> That would be true if e.g. the null array disappeared. As such, this
>>> adds yet another type to the discussion.
>>> ...
>>
>> What I mean is that there will be no reason to discuss the following
>> atrocity any further:
>>
>> void main(){ // (Compiles and runs with DMD)
>>     assert([1].ptr[0..0] !is null);
>>     assert([1][0..0] is null);
>>     int i=0;
>>     assert([1][i..i] !is null);
>>     assert([] is null);
>>     auto x=[1];
>>     assert(x[0..0] !is null);
>>     auto y=[1][i..i];
>> }
>
> Making [] changes exactly one line there if I understand things
> correctly, and does not improve anything much.
>

You don't understand things correctly.

This would be the new behaviour:

void main(){
    assert([1].ptr[0..0] !is null);
    assert([1][0..0] !is null);
    int i=0;
    assert([1][i..i] !is null);
    assert([] !is null);
    auto x=[1];
    assert(x[0..0] !is null);
    auto y=[1][i..i];
}

Notice the 'nice uniformity' there.


>> Furthermore let's look at it from a syntactic viewpoint.
>>
>> Currently we have:
>>
>> - empty arrays of the form cast(T[])null
>> - other empty arrays which are null, eg. []
>> - empty arrays which are not null, eg. [1][i..i]
>>
>> Afterwards we have:
>> - empty arrays of the form cast(T[])null
>> - empty arrays which are not null, eg. [] or [1][i..i]
>>
>> IMO that reduces cognitive load, even if not as much as simply getting
>> rid of cast(T[])null.
>
> The way I see it is:
>
> - we now have two literals for null arrays

Which two? I only see one bulb.

> - we also have the ability to create non-null but empty arrays through
> natural reduction and slicing of arrays
>
> The new setup is:
>
> - we'd have one literal for null arrays
> - we'd still have the ability to create non-null but empty arrays
> through natural reduction and slicing of arrays
> - we'd have Nosferatu in the form of []
> ...

Yah, those are IMO fairly unfair classifications, but I really don't 
want to get into this kind of discussion.