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.