I vote for leaving iota as is. Reasoning:
1. In general, premature micro-optimization is a Bad Thing. A standard
library should aim to be correct, general and reasonably efficient and
handle the 95% of cases well. If you need micro-optimization or are
otherwise in that hardest 5%, you have the core language in which to
roll your own widget.
2. In the case of quick and dirty code, the user probably won't care
much about the speed advantage of using a forward range, and may do
something silly like eagerly evaluate using array() if he/she needs a
bidirectional/random access range, thus worsening the performance
problem instead of solving it.
3. In the case of higher quality code, iota as it currently stands is
only a problem in performance critical code that doesn't need anything
beyond forward access. If someone really needs the speed, it's trivial
to roll one's own iota equivalent that offers only forward access, or
even manually inline and hand optimize it for possibly even more speed.
If the forward range version of iota were the default and someone needed
the bidirectional/random version, it would be less trivial to roll one's
own, as the user might miss the subtle details that make Phobos's
current implementation correct.
On 12/23/2010 1:20 PM, Andrei Alexandrescu wrote:
Per the recent discussion comparing D with Lua, tests suggest that
iota for double is too slow. This is a necessity if iota is a
bidirectional or random-access range. If we allow it to be a forward
range, then performance would be significantly increased.
Do you agree with making iota for floating-point types a forward range?
Andrei
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
