T[new] misgivings

[Sergey Gromov]

Thu, 15 Oct 2009 23:18:22 -0500, Andrei Alexandrescu wrote:

> Jeremie Pelletier wrote:
>> Andrei Alexandrescu wrote:
>>> Jeremie Pelletier wrote:
>>>> Andrei Alexandrescu wrote:
>>>>> Walter Bright wrote:
>>>>>> Andrei Alexandrescu wrote:
>>>>>>> This goes into something more interesting that I thought of after 
>>>>>>> the conversation. Consider:
>>>>>>>
>>>>>>> T[new] a;
>>>>>>> T[] b;
>>>>>>> ...
>>>>>>> a = b;
>>>>>>>
>>>>>>> What should that do?
>>>>>>
>>>>>> Error. T[] cannot be implicitly converted to T[new]
>>>>>
>>>>> Then your argument building on similarity between the two is weakened.
>>>>>
>>>>> T[new] a;
>>>>> T[] b;
>>>>> ...
>>>>> a = [1, 2, 3];
>>>>> b = [1, 2, 3];
>>>>>
>>>>> Central to your argument was that the two must do the same thing. 
>>>>> Since now literals are in a whole new league (they aren't slices 
>>>>> because slices can't be assigned to arrays), the cornerstone of your 
>>>>> argument goes away.
>>>>>
>>>>>
>>>>> Andrei
>>>>
>>>> Simple, assignment to a fails 'cannot cast T[3] to T[new]'.
>>>>
>>>> It's already consistent with slices of different types:
>>>> char[] a = "foo"; // error, cannot cast immutable(char)[] to char[]
>>>> int[new] b = [1, 2, 3]; // error, cannot cast int[3] to int[new]
>>>>
>>>> you have to do:
>>>> char[] a = "foo".dup;
>>>> int[new] b = [1, 2, 3].dup;
>>>>
>>>> Jeremie
>>>
>>> I'd be _very_ unhappy to have to explain to people how in the world we 
>>> managed to make the most intuitive syntax not work at all.
>>>
>>> Andrei
>> 
>> I agree it can be confusing, the first time i tried to assign a string 
>> literal to a char[] in D2 I had to pause for a second to understand what 
>> was happening :)
>> 
>> But what I don't like is that assigning memory from the static data 
>> segment to a resizable array isn't safe. Unless the GC can detect that 
>> the memory it is trying to resize isn't part of the heap and 
>> automatically create a new allocation for it, you're gonna have nasty 
>> side effects.
>> 
>> The compiler could also implicitly copy the slice, but then it should 
>> also automatically copy a "foo" literal when assigned to char[] to keep 
>> consistent.
>> 
>> Jeremie
> 
> Speaking of which, a funny fallout of this a = [1, 2, 3] thing is that 
> we, while striving to avoid all hidden allocations, ended up doing the 
> worst hidden allocation with the simplest and most intuitive syntax.

How about this specification: [1, 2, 3] is an array literal which
*allocates* an array but the allocation can be optimized away if
assigned to a slice.