Array literals MUST be immutable.
grauzone
none at example.net
Fri Feb 19 09:19:21 PST 2010
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.
More information about the Digitalmars-d
mailing list