www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Should conversion of mutable return value to immutable allowed?

reply =?ISO-8859-1?Q?Ali_=C7ehreli?= <acehreli yahoo.com> writes:
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
Feb 24 2011
next sibling parent reply spir <denis.spir gmail.com> writes:
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. This would esp be 
nice for strings, since we regularly need to use char arrays to construct 
textual content.

Denis
-- 
_________________
vita es estrany
spir.wikidot.com
Feb 24 2011
parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
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
Feb 24 2011
next sibling parent Jesse Phillips <jessekphillips+D gmail.com> writes:
Ali Çehreli Wrote:


 I have another question: Does calling .idup copy any data below?
 
 string foo()
 {
      char[] s;
      return s.idup;  // Is the content copied?
 }
 
 Ali
 


Yes, dup stands for duplicate and is a property of arrays.

There was discussion for allowing immutable objects to be created and return
from pure functions.
Feb 24 2011
prev sibling parent Jesse Phillips <jessekphillips+D gmail.com> writes:
Also there is std.exception.assumUnique()
Feb 24 2011
prev sibling next sibling parent Simon Buerger <krox gmx.net> writes:
On 24.02.2011 19:08, 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


Currently, the correct way to do it is to use the phobos function 
assumeUnique, like:

string bar()
{
char[] s;
return assumeUnique(s);
}

Note that this does only little more than casting to immutable, so you 
have to ensure there is no mutable reference left behind.

Anyway, it might be nice if the compiler could detect some trivial 
cases and insert the cast appropriately. But on the other hand, the 
compiler will never to be able to auto-detect all cases, and so its 
cleaner to use assumeUnique explicitly.

- Krox
Feb 24 2011
prev sibling parent Tomek =?ISO-8859-2?B?U293afFza2k=?= <just ask.me> writes:
Ali =C7ehreli napisa=B3:


 Implicit conversions to immutable in the following two functions feel=20
 harmless. Has this been discussed before?
=20
 string foo()
 {
      char[] s;
      return s;     // Error: cannot implicitly convert expression
                    //        (s) of type char[] to string
 }
=20
 string bar()
 {
      char[] s;
      return s ~ s; // Error: cannot implicitly convert expression
                    //        (s ~ s) of type char[] to string
 }
=20
 Is there a reason why that's not possible? I am sure there must be other=


=20

 cases that at least I would find harmless. :)


Indeed. The returned object can be safely set to stone when its only aliase=
s to the outside world point to immutable data. Such a guarantee is express=
ed in today's language by marking the function pure and all its arguments i=
mmutable. The conversion is currently not allowed as the above virtue of im=
mutably pure functions was discovered not too long ago.

If you want it, vote up:
http://d.puremagic.com/issues/show_bug.cgi?id=3D5081

--=20
Tomek
Feb 24 2011