http://d.puremagic.com/issues/show_bug.cgi?id=7310

           Summary: pure function results should implicitly cast to
                    mutable
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: nobody@puremagic.com
        ReportedBy: timon.gehr@gmx.ch


--- Comment #0 from timon.gehr@gmx.ch 2012-01-18 10:51:02 PST ---
The following code should compile
immutable(int)[] foo()pure{return new int[1];}
void main(){int[] x = foo();}

as should this (alternatively it should error out on the first line, not on the
second):
const(int)[] foo()pure{return new int[1];}
void main(){int[] x = foo();}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=7310


timon.gehr@gmx.ch changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|pure function results       |strongly pure function
                   |should implicitly cast to   |results should implicitly
                   |mutable                     |cast to mutable, shared,
                   |                            |and inout


--- Comment #1 from timon.gehr@gmx.ch 2012-01-18 11:55:27 PST ---
On second thought, this should be the case for all type qualifiers. The following code should compile too:

inout(int)[] foo(inout int)pure{return new int[1];}
shared(int)[] foo()pure{return new int[1];}
int[] bar()pure{return new int[1];}
inout(int)[] bar(inout int){inout r = bar(); return r;}
void main(){shared(int)[] a = bar();}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=7310


timon.gehr@gmx.ch changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|strongly pure function      |pure function results
                   |results should implicitly   |should implicitly cast to
                   |cast to mutable, shared,    |mutable, shared, and inout
                   |and inout                   |
           Severity|normal                      |enhancement


--- Comment #2 from timon.gehr@gmx.ch 2012-01-18 12:01:45 PST ---
Of course, there have to be some additional constraints: Namely, if the return value should implicitly convert to <qualifier>, the function parameters all have to implicitly convert to <qualifier>. This could even be checked at call site:

const(int)[] foo(const(int)[] x)pure{return x;}
void main(){
    int[] x = new int[1];
    int[] y = foo(x); // perfectly fine
}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=7310


Stewart Gordon <smjg@iname.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |smjg@iname.com


--- Comment #3 from Stewart Gordon <smjg@iname.com> 2012-01-18 15:32:54 PST ---
I'm not sure about this.  If a function is pure, then multiple calls with the same arguments (or even that return the same value) can potentially be optimised to all use the same copy of the data.  Implicit cast to mutable would mess this up, unless we define the implicit conversion to .dup the result.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=7310



--- Comment #4 from timon.gehr@gmx.ch 2012-01-18 15:40:51 PST ---
The analysis would just have to detect whether or not such an implicit conversion has happened. The compiler has all the information, I don't think it is an issue.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=7310



--- Comment #5 from timon.gehr@gmx.ch 2012-01-18 15:42:35 PST ---
Furthermore, the optimization also applies when it is the other way round (mutable return value implicitly converted to immutable), so the analysis would consider implicit conversions of the return value anyway.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=7310


Don <clugdbug@yahoo.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |clugdbug@yahoo.com.au


--- Comment #6 from Don <clugdbug@yahoo.com.au> 2012-01-18 16:57:39 PST ---
(In reply to comment #5)
> Furthermore, the optimization also applies when it is the other way round (mutable return value implicitly converted to immutable), so the analysis would consider implicit conversions of the return value anyway.

No. The only way an immutably pure function can return a mutable value, is if it created it itself -- so we know it's unique. No analysis of the body of the function is required.

But, if an immutable pure function returns an immutable value, we know nothing. It could be a parameter, or an immutable global variable, or a variable created inside the function.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=7310


timon.gehr@gmx.ch changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID


--- Comment #7 from timon.gehr@gmx.ch 2012-01-18 17:09:48 PST ---
(In reply to comment #6)
> (In reply to comment #5)
> > Furthermore, the optimization also applies when it is the other way round (mutable return value implicitly converted to immutable), so the analysis would consider implicit conversions of the return value anyway.
> 
> No. The only way an immutably pure function can return a mutable value, is if it created it itself -- so we know it's unique. No analysis of the body of the function is required.

This is not what I was suggesting. I am only reasoning about the call-site here.

> 
> But, if an immutable pure function returns an immutable value, we know nothing. It could be a parameter, or an immutable global variable, or a variable created inside the function.

For parameter, see comment #2. immutable global variables are a deal-breaker. Implicitly casting between shared and unshared should still be possible at strongly pure function border. I am opening a separate issue for it.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------