Should .idup simply do nothing for arrays that are already immutable?

[Steven Schveighoffer]

On Fri, 08 Jan 2010 16:07:16 -0500, dsimcha <dsimcha at yahoo.com> wrote:

> import std.stdio;
>
> void main() {
>     immutable foo = "FOO";
>     immutable bar = foo.idup;
>     writeln(foo.ptr, '\t', bar.ptr);
> }
>
> Output:
> 42C090  97AE40
>
> Should we define .idup on an already-immutable array to simply do  
> nothing?  It
> seems that there is never any good reason to copy an immutable array,  
> and it
> would avoid the need to either needlessly copy an array or explicitly  
> check
> for immutability in metaprogramming situations.

In fact, I think the whole dup notion needs to be revisited.  idup and dup  
currently suffer from a very unsafe bug -- they implicitly cast the  
result, even if the array contents are references  
(http://d.puremagic.com/issues/show_bug.cgi?id=3550).

Also, currently there is only one function for duping and it doesn't know  
whether the result is going to be immutable or mutable.

My opinion is that it's better at this point in time to get rid of idup  
and make dup always copy its contents, and always return the same type  
it's called with.  If you want to transform to immutable or away from  
immutable, it's on you to do the cast afterwards.  That's the only  
possible safe solution ATM.  idup can be an array function which does the  
right thing or refuses to compile (see the bug).  You'd probably want cdup  
and mdup also.

If, in the future, we are able to get a unique qualifier, then changing  
dup to returning unique will naturally work the way it should.  As it is  
now, it is a hack and should be fixed.

-Steve