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

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

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

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.

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

Also there is std.exception.assumUnique()

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