www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 5081] New: Pure functions as initializers for immutable structures

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5081

           Summary: Pure functions as initializers for immutable
                    structures
           Product: D
           Version: D2
          Platform: Other
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: tomeksowi gmail.com



PDT ---
From my post on D newsgroup:

Initializing immutable structures is a source of constant grief. Anything
non-trivial requires instancing a mutable structure, initializing it, and then
either casting to immutable (it's up to you to ensure no alias leaked) or, not
to violate the type system, duplicate the whole.

Yet, if there was a situation where the alias leaking is under control, casting
would be safe. Perhaps pure* functions are such a place. They can only touch
the immutable world, whether through globals or through their parameters. So if
one initializes the returned structure with a reference to the outside world,
it will be immutable. And if you stuff the structure with anything mutable, it
must have been created within the function's body, so no alias leaks.

I think it is safe to implicitly convert a pure function's return value to
immutable.

* here by pure I mean either the old pure** when it still had immutable
arguments, or Don's "immutably pure".

Pure functions could be used as follows:

pure T make(Args args) { ... }
unittest {
    T t = make(...); // good
    immutable T t = make(...); // also good
}

Michel Fortin also noticed a nice-to-have: if at the call site you know that
all the arguments you're feeding the function with are immutable, then you can
automatically cast the result to immutable, even if the function can also
accept const arguments.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 19 2010
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5081


bearophile_hugs eml.cc changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bearophile_hugs eml.cc



See also bug 5147 for a different solution

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 31 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5081




12:47:49 PST ---



 Michel Fortin also noticed a nice-to-have: if at the call site you know that
 all the arguments you're feeding the function with are immutable, then you can
 automatically cast the result to immutable, even if the function can also
 accept const arguments.


Note actually that as long as you can verify the return value did not come
directly from the parameters, it's also possible to implicitly cast to
immutable.

For example:

pure T[] mydup(T)(const(T)[] param) {...}

It's provable that the return value did not come from param (without a cast),
because you can't implicitly cast param to T[].  So you can cast the result to
immutable, even if param began as mutable.

This might be really tricky to implement though, there can be all sorts of
weird cases.

But if this could be accomplished, it would completely negate the need for
idup.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 24 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5081


yebblies <yebblies gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |patch
                 CC|                            |yebblies gmail.com



https://github.com/D-Programming-Language/dmd/pull/218

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 08 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5081


Walter Bright <bugzilla digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |bugzilla digitalmars.com
         Resolution|                            |FIXED



19:48:32 PDT ---
https://github.com/D-Programming-Language/dmd/commit/af3efb7e963a65b5abe639df04add44a24d75cfa

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Aug 24 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5081




This is a new part of the design of D purity, and a significant improvement for
D usability.

I think the behaviours shown by this little program are correct, but I think
that error message needs to be improved (completed with more details), because
in some cases (like foo1) that's an acceptable operation:


string foo1() pure {
    const(char[]) s2 = ['a'];
    return s2;
}
string foo2() pure {
    return ['a'];
}
string foo3(immutable char[] s) pure {
    return s;
}
string foo4(in char[] s1, immutable char[] s2) pure {
    return s2;
}
string foo5(in char[] s) pure {
    return s; // Error: cannot implicitly convert expression (s) of type
const(char[]) to string
}
void main() {
    immutable r1 = foo1();             // OK
    immutable r2 = foo2();             // OK
    immutable r3 = foo3(['a']);        // OK
    immutable r4 = foo4(['a'], ['b']); // OK
    immutable r5 = foo5(['a']);        // Error
}


Good and complete error messages are needed to help the programmer understand
her mistake and build a correct model of D semantics in her head.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Aug 24 2011
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5081







 I think the behaviours shown...


Sorry, that was out of place in this enhancement request. I have opened bug
6553 for it.

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