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

           Summary: Cannot copy std.algorithm.map
           Product: D
           Version: D2
          Platform: Other
        OS/Version: Windows
            Status: NEW
          Keywords: rejects-valid
          Severity: regression
          Priority: P2
         Component: DMD
        AssignedTo: nobody@puremagic.com
        ReportedBy: dsimcha@yahoo.com


--- Comment #0 from David Simcha <dsimcha@yahoo.com> 2011-05-06 22:35:37 PDT ---
import std.algorithm;

void fun(T)(T x) {
    T xSaved;
}


unittest {
    double[] x;
    fun(map!"a * a"(x));
}

DMD 2.053 beta:
test9.d(4): Error: function std.algorithm.map!("a * a").map!(double[]).map is a
nested function and cannot be accessed from __unittest1
test9.d(4): Error: function std.algorithm.map!("a * a").map!(double[]).map is a
nested function and cannot be accessed from fun

-- 
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=5939


kennytm@gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kennytm@gmail.com


--- Comment #1 from kennytm@gmail.com 2011-05-06 23:15:51 PDT ---
The problem isn't copying a map, but initializing the type using 'T xSaved'. If you use 'T xSaved = x;' it compiles. A reduced example:

-----------------------------
import std.algorithm;
void main() {
    typeof(map!"a"([0])) a;
}
-----------------------------
x.d(3): Error: function std.algorithm.map!("a").map!(int[]).map is a nested
function and cannot be accessed from main
-----------------------------

-- 
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=5939



--- Comment #2 from kennytm@gmail.com 2011-05-06 23:52:03 PDT ---
The bug is introduced in commit 1083bd4e
(https://github.com/D-Programming-Language/phobos/commit/1083bd4e7b4ef0475084d7eab2e67c65e511c3d4#L1L160),
where the return type of map changes from an external private struct to an
inner struct.

-- 
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=5939


Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugzilla@digitalmars.com


--- Comment #3 from Walter Bright <bugzilla@digitalmars.com> 2011-05-08 22:11:20 PDT ---
A reduced test case:

template map(fun...) {
    auto map(Range)(Range r) {
        struct Result {
            this(double[] input) {
            }
        }

        return Result(r);
    }
}

void test() {
    double[] x;
    typeof(map!"a"(x)) a;
}

-- 
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=5939



--- Comment #4 from Walter Bright <bugzilla@digitalmars.com> 2011-05-08 22:37:58 PDT ---
I'm going to argue this is not a compiler bug.

The return type from map (call it T) is a private, opaque data type. The only
way to get an instance of T is by calling map(). T cannot be default
constructed - hence the error message.

This is why:

    auto a = map!"a"([0]);

works, and

    typeof(map!"a"([0])) a;

fails.

Note that you can do:

    typeof(map!"a"([0])) a = void;

because no default construction is attempted.

The default construction cannot happen outside of map() because it requires the
stack frame of map() to do it.

The error message, of course, is not so easy to decipher.

-- 
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=5939



--- Comment #5 from David Simcha <dsimcha@yahoo.com> 2011-05-09 14:43:24 PDT ---
(In reply to comment #4)
> I'm going to argue this is not a compiler bug.
> 
> The return type from map (call it T) is a private, opaque data type. The only
> way to get an instance of T is by calling map(). T cannot be default
> constructed - hence the error message.

I agree with you in principle, but heavily using types that can't be default constructed in public APIs is going to subtly break a lot of generic code when it tries to use such types.  If it's not a compiler bug then it's bad library design.

-- 
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=5939


yebblies <yebblies@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |yebblies@gmail.com
          Component|DMD                         |Phobos
           Platform|Other                       |All
         AssignedTo|nobody@puremagic.com        |andrei@metalanguage.com
         OS/Version|Windows                     |All


--- Comment #6 from yebblies <yebblies@gmail.com> 2011-07-12 23:00:10 EST ---
Maybe this is intentional and therefore not a bug?  It doesn't make any sense for private structs to be able to be default constructed, but this is a useful thing to do with the result of map.  Andrei?

-- 
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=5939



--- Comment #7 from Andrei Alexandrescu <andrei@metalanguage.com> 2011-07-12 08:39:19 PDT ---
This is one of those things that could go either way. I see merit in restricting the result of "map" for direct consumption, without allowing creating an empty result without a corresponding map call.

On the other hand, it's often impossible to do so. Consider the many filtering functions that take a range and build additional functionality on top of it. Such functions need to create a range that contains the subject range as a member. It's reasonable to require that map can be combined with such functions.

I think it's best to fix this - e.g. by storing a null frame pointer in the default-constructed object.

-- 
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=5939


Andrei Alexandrescu <andrei@metalanguage.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
         AssignedTo|andrei@metalanguage.com     |bugzilla@digitalmars.com


--- Comment #8 from Andrei Alexandrescu <andrei@metalanguage.com> 2012-01-17 20:50:09 PST ---
reassigning to walter

-- 
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=5939



--- Comment #9 from Walter Bright <bugzilla@digitalmars.com> 2012-02-05 16:27:10 PST ---
Using null for the frame pointer works in my reduced example, but not in David's original one - it seg faults at runtime.

Perhaps changing map to make its inner struct 'static' (so it won't require a context pointer) will do the trick.

Back to you, Andrei!

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