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