Should conversion of mutable return value to immutable allowed?

[Ali Çehreli]

On 02/24/2011 10:28 AM, spir wrote:
 > On 02/24/2011 07:08 PM, Ali Çehreli wrote:
 >> Implicit conversions to immutable in the following two functions feel
 >> harmless.
 >> Has this been discussed before?
 >>
 >> string foo()
 >> {
 >> char[] s;
 >> return s; // Error: cannot implicitly convert expression
 >> // (s) of type char[] to string
 >> }
 >>
 >> string bar()
 >> {
 >> char[] s;
 >> return s ~ s; // Error: cannot implicitly convert expression
 >> // (s ~ s) of type char[] to string
 >> }
 >>
 >> Is there a reason why that's not possible? I am sure there must be
 >> other cases
 >> that at least I would find harmless. :)
 >>
 >> Ali
 >
 > I'm all for that. Can hardly how auto conversion in the sense mutable
 > --> immutable could be harmful, but may miss a meaningful point.

It shouldn't be allowed if a reference to that char[] is left behind. 
Otherwise although the receiver would think that the data wouldn't 
change; it could be changed by that other reference.

struct S
{
     char[] s;

     string foo()
     {
         return s;    // <-- Must not be allowed
     }
}

But when the object in question is about to go out of scope? I don't 
know. On the other hand, reducing some implicit behavior is also good.

 > This
 > would esp be nice for strings, since we regularly need to use char
 > arrays to construct textual content.
 >
 > Denis

I have another question: Does calling .idup copy any data below?

string foo()
{
     char[] s;
     return s.idup;  // Is the content copied?
}

Ali