http://d.puremagic.com/issues/show_bug.cgi?id=4264
--- Comment #4 from yebblies <yebbl...@gmail.com> 2010-07-16 21:17:49 PDT ---
(In reply to comment #3)
>
> But this too doesn't work:
>
> import std.algorithm, std.conv, std.range;
> void main() {
> auto r1 = map!(to!(string, uint))(iota(20));
> }
>
>
> import std.algorithm, std.conv, std.range;
> void main() {
> auto r1 = map!(to!(string, int))(iota(20));
> }
>
You're right. But this is not a problem with map, I think this is bug337.
void t1(U = int)(int a)
{
}
void t1(U = int)()
{
}
void t2(U = int, T = int)(int a)
{
}
void t2(U = int, T = int)()
{
}
void main() {
t1!()(1); // works
t1!()(); // works
t1!(int)(1); // fails
t1!(int)(); // fails
t2!()(1); // works
t2!()(); // works
t2!(int)(1); // works
t2!(int)(); // works
t2!(int,int)(1); // fails
t2!(int,int)(); // fails
}
It can probably be worked around by combining the radix and non-radix form of
to!(string,int).
Maybe a separate bug?
> If you perform a map! on an iterable that has a length, then map! detects it
> at
> compile-time and offers a length attribute, otherwise it's not offered.
>
> So map! and other similar higher order functions can adapt and offer as much
> as
> possible.
>
> If the iterable given to map! has just an opApply, then map! can offer just an
> opApply, for an iteration that can't be resumed.
Ok, I see your point, but if map is going to work with opApply it will no
longer be able to provide the standard range interface.
Either way this is an enhancement request and not a bug.
map!func(structWithOpApply) would also no longer work with most of
std.algorithm without extensive (and maybe impossible) modifications.
> array() can work with anything that can be iterated by foreach.
Agreed.
array() is special in that it always evaluates the entire range immediately.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
