www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 7310] New: pure function results should implicitly cast to mutable

reply d-bugmail puremagic.com writes:
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: -------
Jan 18 2012
next sibling parent d-bugmail puremagic.com writes:
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: -------
Jan 18 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Jan 18 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Jan 18 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Jan 18 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Jan 18 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Jan 18 2012
prev sibling parent d-bugmail puremagic.com writes:
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: -------
Jan 18 2012