digitalmars.D.bugs - [Issue 5939] New: Cannot copy std.algorithm.map
- d-bugmail puremagic.com (30/30) May 06 2011 http://d.puremagic.com/issues/show_bug.cgi?id=5939
- d-bugmail puremagic.com (20/20) May 06 2011 http://d.puremagic.com/issues/show_bug.cgi?id=5939
- d-bugmail puremagic.com (9/9) May 06 2011 http://d.puremagic.com/issues/show_bug.cgi?id=5939
- d-bugmail puremagic.com (23/23) May 08 2011 http://d.puremagic.com/issues/show_bug.cgi?id=5939
- d-bugmail puremagic.com (20/20) May 08 2011 http://d.puremagic.com/issues/show_bug.cgi?id=5939
- d-bugmail puremagic.com (10/15) May 09 2011 http://d.puremagic.com/issues/show_bug.cgi?id=5939
- d-bugmail puremagic.com (16/16) Jul 12 2011 http://d.puremagic.com/issues/show_bug.cgi?id=5939
- d-bugmail puremagic.com (15/15) Jul 12 2011 http://d.puremagic.com/issues/show_bug.cgi?id=5939
- d-bugmail puremagic.com (11/11) Jan 17 2012 http://d.puremagic.com/issues/show_bug.cgi?id=5939
- d-bugmail puremagic.com (10/10) Feb 05 2012 http://d.puremagic.com/issues/show_bug.cgi?id=5939
- d-bugmail puremagic.com (18/20) Feb 07 2012 http://d.puremagic.com/issues/show_bug.cgi?id=5939
- d-bugmail puremagic.com (7/13) Feb 07 2012 http://d.puremagic.com/issues/show_bug.cgi?id=5939
- d-bugmail puremagic.com (10/10) Feb 07 2012 http://d.puremagic.com/issues/show_bug.cgi?id=5939
- d-bugmail puremagic.com (15/15) Jul 24 2012 http://d.puremagic.com/issues/show_bug.cgi?id=5939
- d-bugmail puremagic.com (16/22) Jul 25 2012 http://d.puremagic.com/issues/show_bug.cgi?id=5939
- d-bugmail puremagic.com (10/10) Jul 25 2012 http://d.puremagic.com/issues/show_bug.cgi?id=5939
- d-bugmail puremagic.com (16/22) Jul 25 2012 http://d.puremagic.com/issues/show_bug.cgi?id=5939
- d-bugmail puremagic.com (12/12) Jul 30 2012 http://d.puremagic.com/issues/show_bug.cgi?id=5939
- d-bugmail puremagic.com (9/9) Jul 30 2012 http://d.puremagic.com/issues/show_bug.cgi?id=5939
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
d-bugmail puremagic.com
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
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
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
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
http://d.puremagic.com/issues/show_bug.cgi?id=5939I'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
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
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
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
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
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
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 pointerHow 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
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
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
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
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
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
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
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