[Issue 5939] Cannot copy std.algorithm.map
http://d.puremagic.com/issues/show_bug.cgi?id=5939 --- Comment #17 from github-bugzi...@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: ---
[Issue 5939] Cannot copy std.algorithm.map
http://d.puremagic.com/issues/show_bug.cgi?id=5939 Andrei Alexandrescu and...@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: ---
[Issue 5939] Cannot copy std.algorithm.map
http://d.puremagic.com/issues/show_bug.cgi?id=5939 Jonathan M Davis jmdavisp...@gmx.com changed: What|Removed |Added CC||jmdavisp...@gmx.com --- Comment #13 from Jonathan M Davis jmdavisp...@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: ---
[Issue 5939] Cannot copy std.algorithm.map
http://d.puremagic.com/issues/show_bug.cgi?id=5939 --- Comment #15 from Jonathan M Davis jmdavisp...@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: ---
[Issue 5939] Cannot copy std.algorithm.map
http://d.puremagic.com/issues/show_bug.cgi?id=5939 Don clugd...@yahoo.com.au changed: What|Removed |Added CC||clugd...@yahoo.com.au --- Comment #14 from Don clugd...@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: ---
[Issue 5939] Cannot copy std.algorithm.map
http://d.puremagic.com/issues/show_bug.cgi?id=5939 Dmitry Olshansky dmitry.o...@gmail.com changed: What|Removed |Added CC||dmitry.o...@gmail.com --- Comment #16 from Dmitry Olshansky dmitry.o...@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: ---
[Issue 5939] Cannot copy std.algorithm.map
http://d.puremagic.com/issues/show_bug.cgi?id=5939 d...@dawgfoto.de changed: What|Removed |Added CC||d...@dawgfoto.de --- Comment #10 from d...@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: ---
[Issue 5939] Cannot copy std.algorithm.map
http://d.puremagic.com/issues/show_bug.cgi?id=5939 --- Comment #11 from Walter Bright bugzi...@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: ---
[Issue 5939] Cannot copy std.algorithm.map
http://d.puremagic.com/issues/show_bug.cgi?id=5939 --- Comment #12 from d...@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: ---
[Issue 5939] Cannot copy std.algorithm.map
http://d.puremagic.com/issues/show_bug.cgi?id=5939 --- Comment #9 from Walter Bright bugzi...@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: ---
[Issue 5939] Cannot copy std.algorithm.map
http://d.puremagic.com/issues/show_bug.cgi?id=5939 Andrei Alexandrescu and...@metalanguage.com changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|and...@metalanguage.com |bugzi...@digitalmars.com --- Comment #8 from Andrei Alexandrescu and...@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: ---
[Issue 5939] Cannot copy std.algorithm.map
http://d.puremagic.com/issues/show_bug.cgi?id=5939 yebblies yebbl...@gmail.com changed: What|Removed |Added CC||yebbl...@gmail.com Component|DMD |Phobos Platform|Other |All AssignedTo|nob...@puremagic.com|and...@metalanguage.com OS/Version|Windows |All --- Comment #6 from yebblies yebbl...@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: ---
[Issue 5939] Cannot copy std.algorithm.map
http://d.puremagic.com/issues/show_bug.cgi?id=5939 --- Comment #7 from Andrei Alexandrescu and...@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: ---
[Issue 5939] Cannot copy std.algorithm.map
http://d.puremagic.com/issues/show_bug.cgi?id=5939 --- Comment #5 from David Simcha dsim...@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: ---
[Issue 5939] Cannot copy std.algorithm.map
http://d.puremagic.com/issues/show_bug.cgi?id=5939
Walter Bright bugzi...@digitalmars.com changed:
What|Removed |Added
CC||bugzi...@digitalmars.com
--- Comment #3 from Walter Bright bugzi...@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: ---
[Issue 5939] Cannot copy std.algorithm.map
http://d.puremagic.com/issues/show_bug.cgi?id=5939 --- Comment #4 from Walter Bright bugzi...@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: ---
[Issue 5939] Cannot copy std.algorithm.map
http://d.puremagic.com/issues/show_bug.cgi?id=5939
kenn...@gmail.com changed:
What|Removed |Added
CC||kenn...@gmail.com
--- Comment #1 from kenn...@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: ---
[Issue 5939] Cannot copy std.algorithm.map
http://d.puremagic.com/issues/show_bug.cgi?id=5939 --- Comment #2 from kenn...@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: ---
