On Thu, 08 Oct 2009 22:07:32 +0400, Andrei Alexandrescu
<[email protected]> wrote:
Consider:
auto c = [ 2.71, 3.14, 6.023e22 ];
c ~= 2.21953167;
Should this work? Currently it doesn't because c's type is deduced as
double[3].
The literal can initialize either double[3] or double[], so the question
is only what the default should be when "auto" is used.
Thoughts?
Andrei
I was just about to bump a similar topic.
I strongly believe typeof(c) must be immutable(double)[3].
There are 2 problems in D with current design:
1) The following code:
auto c = [ 2.71, 3.14, 6.023e22 ];
always allocates memory from a heap. In many cases, a read-only view of
that array would suffice. In case a mutation is needed, no one stops you
from dup'ing that array:
auto c = [ 2.71, 3.14, 6.023e22 ].dup;
2) There is an inconsistency with strings:
auto c1 = "Hello"; // immutable
auto c2 = ['H', 'e', 'l', 'l', 'o']; // mutable
I don't like hidden allocations like this to present in D. I believe this
is not what most users expect to happen.
Back to your question, I believe it should be fixed-size and immutable.
Once again, no one stops you from using "[]":
auto c = [ 2.71, 3.14, 6.023e22 ][]; // a slice is returned
The opposite is impossible - you can't get a fixed-sized array from a
dynamic one.
Another question is, what type should .dup return? T[new] or T[]? (The
former one, probably, since the latter one is accessible via .dup[]
syntax...) Anyway, what is the state of T[new] in future of D?
