Steven Schveighoffer wrote:
Don wants to make array literals immutable; that means you couldn't
just assign them to int[] anyway. In both cases, you'd have to use
.dup to use them as normal, mutable arrays.
That's fine, if I don't specify dup by accident, the compiler would
complain. In Denis' proposal, the compiler doesn't complain it just
silently compiles.
True enough, but you have this problem _anyway_, as Denis pointed out.
And the solution will remove those safety problems for array literals as
well.
I don't know if the compiler has enough magic to detect the escaping
reference by itself, but it would be great if that worked.
Array literals being static arrays would be very handy in other
places. Wouldn't it be nice if you could just use them for small fixed
size vectors (wasn't that one of the reasons to make static arrays
value types)? Then you could write assert([1, 2] + [3, 4] == [4, 6]).
No silly struct vector "classes" needed.
Does this work with static arrays? I thought you needed to use the
slicing notation. In any case, using literals in array operations would
be nifty. I don't think you need to have array literals be statically
sized to accomplish this.
Yes, right now you need []. I would hope some day it will work without.
Array operations on static arrays would enable the compiler to emit a
single SSE instruction for an operation. With dynamic arrays, the
compiler has to insert additional instructions for boundary checks,
unpacking the array elements, etc.; and it couldn't just allocate the
full vector in SSE registers either.
I don't quite know why it can't just behaves as if "array" was
declared on module level (or as, um, the other "static").
Essentially, that is what an immutable array is. The difference is in
type inference.
Even today, the compiler could just do the right thing and allow
"static" initializers even for stack allocated values. By the way, this
is probably also the reason why nobody likes struct initializers. They
work as static initializers only.
If array literals become immutable, being able to initialize static
arrays easily from runtime values *without* heap allocation would be a
very nice feature to have. Perhaps you could use variables in an array
literal only if they are used to initialize statically sized arrays.
This problem needs to be discussed if we are to get immutable array
literals.
Yes, but the compiler doesn't do that even today. Was it too hard to
implement? Didn't Walter care enough? Or didn't he know of this special
case?
Beside all these points, if array literals are static, then obtaining an
immutable array literal requires a dup or a global. I don't think
The immutable array could be on the stack as well (it would have the
type immutable(T[X]) for some integer X).
that's a good strategy. Another point is IFTI and auto type detection
-- what is most useful as an automatic type for array literals? I'd say
immutable arrays are more useful because they can be easily converted to
all other types of arrays, and it is consistent with string literals.
That's a good point.
The only caveat as you brought up is using runtime values inside a
literal to initialize a static array. I think this can be special-cased
by the compiler, but I'm not sure.
At least it wouldn't conflict with the semantics. But Don had this
argument with efficiency and unobvious heal allocations. Immutable array
literals don't solve this. Of course you could still force the arguments
for array literals to be compile time values.
