Array literals MUST be immutable.

Michael Rynn michaelrynn at optusnet.com.au
Wed Feb 17 17:07:20 PST 2010


On Wed, 17 Feb 2010 07:49:09 -0600, Andrei Alexandrescu wrote:

> Don wrote:
>> This is for me the last remaining D2 issue. I've mentioned this several
>> times before. Mutable array 'literals' are wrong on so many levels.
>> Here are some of the issues, listed in decreasing importance.
> [snip]
> 
> I agree. How do you see we should change the language to fix things?
> 
> Andrei

I am trying to improve my understanding here by reasoning some of it out a
bit, and trying to figure out what is everyone elses probably implicitly
understands.

Start looking at DPL C heritage, what is the behaviour of array literals
in C?  What does a good C compiler do?

Whenever we put something like this in code,

Elem* = [ Piece of literal data ]

The compiler has created a representation of the data which of these? 1.
pointer to protected read - only memory? (Probably would declare const) 2.
returned a pointer to a writeable static memory location in the code- data
image, which is start of the array data. If so then the data can be
changed but not extended in size without reallocation.

3. allocated a copy of the original data, location known only to compiler,
to heap or stack allocated memory block, and assigned to the pointer
variable.

How does this vary with static and stack context?

I would like to (wishfully) think that what happens is that it looks like
the code text in my editor.  The value of the literal in my source code
after being assigned is not destroyed by further manipulation of Elem*. It
still exists in the original source, so it should still exist in the
binary image, and can be recalled again.  So thats what I would define as
the "immutable source".

This happens now for string type, they are source immutable. Changes can
be only done to a mutable copy.  I have got used to that.



So what would really break if this was true of all array literals? How
hard is it to do in the current D2 compiler? How does it affect the
runtime typeinfo system? (I am still getting used to that).

Has anyone tried this in an experimental version of D2?
  
I suppose we can always write code that can copy from immutable source
where necessary? Is it possible to be able make mutable copies more
easily?

Is there anything that is really awkward in D2 working with immutable
string type, that cannot be done without resorting to mutable character
literals?   If not, then the principle can be applied to all "immutable
source".

But for those who would like mutable static memory initialised for some ,
might there be a way of telling the compiler that we wish to abuse the
memory image?

char[] = cast(mutable(char)[]) "I can overwrite this initialization string
for all time"; // points to original binary image

char[] = "I can overwrite this source string".dup;

The example given :-
   int*[] foo(int *p)
   {
     return [p, p + 1];
   }

Why would you make such a function?
Why not make it locally without the function call overhead?

int *p = &something;
...
int*[] mypointers = [p, p+1];  // this should not be a literal, but memory
allocated like a if its on the stack filled in dynamically at point of 
execution, and not immutable?

p, p+1 are the initialisation values.

int*[] mypointers = [&static1, &static2];  // this looks like a literal, 
known at compile time. but could also be memory filled in dynamically at 
point of execution.  If mypointers is static then it is immutable?.

How does it work for struct?


Michael Rynn...




More information about the Digitalmars-d mailing list