T[new] misgivings

[Jeremie Pelletier]

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