Array type conversion

[Mark Burnett]

> > > Treating a container of derived as a container
> > > of base is an error.

> @OP: I raised this about a year ago and nobody seemed bothered then; I don't
> imagine that's changed.

After playing around a bit more, I've discovered that (at least with gdc) rewriting the addfavoritefruit function to use the ~= operator to append institutes copy on write by default, while this is *not* the case for the previously posted indexed veresion.

If the keyword "in" guaranteed that all internal writes were copies, then it would probably be unnecessary to change the implicit conversion behavior.  No one in their right mind would pass derived[] to a f(inout base[]), so the only time the issue would arise is in the local scope, which at least narrows the potential bug down for the programmer.

So basically, is there a reason for the following distinction?

foo(in baseT [] base)
{
base[27] = new derived2;  // does not create a copy -- not correct, see below

base ~= new derived2;  // creates a copy
}

If not, a consistent change to the implimentation would have practically no effect on the language specification, while (for practical purposes) fixing this problem.

Correction:  as I was experimenting with this some more I noticed that base[i] = ...; *does* seem to create a copy, but it does so *after* the assignment takes place (during the return?).  If this is really the case, it's almost certainly unintended, and changing it would eliminate this problem for many purposes.

Mark
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fruit6.d
Type: application/octet-stream
Size: 1115 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20070428/08208955/attachment.obj>