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


dawg@dawgfoto.de changed:

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


--- Comment #10 from dawg@dawgfoto.de 2012-02-07 13:57:03 PST ---
>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: -------

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



--- Comment #11 from Walter Bright <bugzilla@digitalmars.com> 2012-02-07 15:31:45 PST ---
(In reply to comment #10)
> ----
> 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: -------

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



--- Comment #12 from dawg@dawgfoto.de 2012-02-07 19:06:25 PST ---
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: -------

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


Jonathan M Davis <jmdavisProg@gmx.com> changed:

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


--- Comment #13 from Jonathan M Davis <jmdavisProg@gmx.com> 2012-07-24 23:55:57 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: -------

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


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

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


--- Comment #14 from Don <clugdbug@yahoo.com.au> 2012-07-25 01:21:56 PDT ---
(In reply to comment #13)
> 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: -------

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



--- Comment #15 from Jonathan M Davis <jmdavisProg@gmx.com> 2012-07-25 01:31:21 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: -------

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


--- Comment #16 from Dmitry Olshansky <dmitry.olsh@gmail.com> 2012-07-25 01:52:26 PDT ---
(In reply to comment #15)
> 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: -------

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



--- Comment #17 from github-bugzilla@puremagic.com 2012-07-30 10:42:37 PDT ---
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 Merge pull request #728 from 9rnsr/fix5939

Issue 5939 - Cannot copy std.algorithm.map

-- 
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|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED


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