Should conversion of mutable return value to immutable allowed?
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
Re: Should conversion of mutable return value to immutable allowed?
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
Re: Should conversion of mutable return value to immutable allowed?
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
Re: Should conversion of mutable return value to immutable allowed?
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
Re: Should conversion of mutable return value to immutable allowed?
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.
Re: Should conversion of mutable return value to immutable allowed?
Also there is std.exception.assumUnique()
Re: Should conversion of mutable return value to immutable allowed?
Ali Çehreli napisał:
> 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. :)
Indeed. The returned object can be safely set to stone when its only aliases to
the outside world point to immutable data. Such a guarantee is expressed in
today's language by marking the function pure and all its arguments immutable.
The conversion is currently not allowed as the above virtue of immutably pure
functions was discovered not too long ago.
If you want it, vote up:
http://d.puremagic.com/issues/show_bug.cgi?id=5081
--
Tomek
