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