www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 5939] New: Cannot copy std.algorithm.map

reply d-bugmail puremagic.com writes:
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



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: -------
May 06 2011
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5939


kennytm gmail.com changed:

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



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: -------
May 06 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5939




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: -------
May 06 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5939


Walter Bright <bugzilla digitalmars.com> changed:

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



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: -------
May 08 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5939




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: -------
May 08 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5939





 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: -------
May 09 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
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



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: -------
Jul 12 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5939




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: -------
Jul 12 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
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



20:50:09 PST ---
reassigning to walter

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 17 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5939




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: -------
Feb 05 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5939


dawg dawgfoto.de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dawg dawgfoto.de



Perhaps changing map to make its inner struct 'static' (so it won't require a
context pointer) will do the trick.
This is a no-go, it would break every map parameter that needs a frame pointer. ---- int base = 2; map!(a => a + base)(new int[](10)); ---- What we should do to solve this is to infer if a templated struct really needs a frame pointer, thus creating less nested structs in the first place. Other than that it doesn't make sense to allow instantiation of nested structs outside of their scope. We should refine the specification. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Feb 07 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5939




15:31:45 PST ---

 ----
 int base = 2;
 map!(a => a + base)(new int[](10));
 ----
 What we should do to solve this is to infer if a templated struct really needs
 a frame pointer
How else could it access 'base'? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Feb 07 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5939




Ah, I didn't wanted to confuse here.
My example was a case for why Result could not be a static struct.
As such it shouldn't be default constructible.
David's example OTOH is a case where a context pointer in Result is not needed
at all, i.e. we don't need to treat it as nested struct.

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


Jonathan M Davis <jmdavisProg gmx.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jmdavisProg gmx.com



PDT ---
I definitely think that we need to be able to get at the init values of
Voldemort types. Too much generic code needs init for it to make sense to do
otherwise. Not to mention, init is normally a public property, and you can call
public functions on Voldemort types just fine (e.g. front, popFront, etc.). If
the creator of the Voldemort type really wants to make it so that you can't use
its init value, then they can  disable it.

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


Don <clugdbug yahoo.com.au> changed:

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




 I definitely think that we need to be able to get at the init values of
 Voldemort types. Too much generic code needs init for it to make sense to do
 otherwise. Not to mention, init is normally a public property, and you can call
 public functions on Voldemort types just fine (e.g. front, popFront, etc.). If
 the creator of the Voldemort type really wants to make it so that you can't use
 its init value, then they can  disable it.
But it requires the frame pointer of the function where it was defined. I think it's an impossible request. Voldemort types cannot merely not be named outside their enclosing function, they cannot be created. It's not just a namespace privacy. If you are using one, you are saying that .init does not exist for that type. I think in this case it is wrong library design -- they shouldn't be used here. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jul 25 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5939




PDT ---
Well, if it can't be done, I think that it calls into question the whole idea
of Voldemort types. In principle, they're really cool, but we keep running into
issues like this with them.

So much is built around having init available, that it's really truly annoying
when it's not.

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


Dmitry Olshansky <dmitry.olsh gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dmitry.olsh gmail.com



01:52:26 PDT ---

 Well, if it can't be done, I think that it calls into question the whole idea
 of Voldemort types. In principle, they're really cool, but we keep running into
 issues like this with them.
 
I was pondering this very question for a long time since they were forced into std.algorithm. Also correct me if I'm wrong but doesn't frame pointer requirement means that frame is *always* allocated on GC heap? If it's true I suggest we kill all of them in Phobos with extreme prejudice as they not only bogus but harm performance.
 So much is built around having init available, that it's really truly annoying
 when it's not.
-- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jul 25 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5939




Commits pushed to master at https://github.com/D-Programming-Language/phobos

https://github.com/D-Programming-Language/phobos/commit/cedddcd23e00d0a4144ed7c507422b8a41bc5900
fix Issue 5939 - Cannot copy std.algorithm.map

Move out Voldemort types to modle level.

https://github.com/D-Programming-Language/phobos/commit/09ea7f599b6cb7c9cadf3724c21aa83f3c486a79


Issue 5939 - Cannot copy std.algorithm.map

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


Andrei Alexandrescu <andrei metalanguage.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED


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