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
Comment #1 by kennytm — 2011-05-06T23:15:51Z
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
-----------------------------
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;
}
Comment #4 by bugzilla — 2011-05-08T22:37:58Z
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.
Comment #5 by dsimcha — 2011-05-09T14:43:24Z
(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.
Comment #6 by yebblies — 2011-07-12T06:00:10Z
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?
Comment #7 by andrei — 2011-07-12T08:39:19Z
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.
Comment #8 by andrei — 2012-01-17T20:50:09Z
reassigning to walter
Comment #9 by bugzilla — 2012-02-05T16:27:10Z
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!
Comment #10 by code — 2012-02-07T13:57:03Z
>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.
Comment #11 by bugzilla — 2012-02-07T15:31:45Z
(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'?
Comment #12 by code — 2012-02-07T19:06:25Z
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.
Comment #13 by issues.dlang — 2012-07-24T23:55:57Z
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.
Comment #14 by clugdbug — 2012-07-25T01:21:56Z
(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.
Comment #15 by issues.dlang — 2012-07-25T01:31:21Z
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.
Comment #16 by dmitry.olsh — 2012-07-25T01:52:26Z
(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.
Comment #17 by github-bugzilla — 2012-07-30T10:42:37Z