https://issues.dlang.org/show_bug.cgi?id=13877
safety0ff.bugz <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] Hardware|x86 |All OS|Windows |All --- Comment #3 from safety0ff.bugz <[email protected]> --- IMO the problem is that join assumes that traversal of the range of ranges is cheap. All the optimization is doing is avoiding reallocation costs while building the array of results (by computing length then allocating appropriately sized array for the results.) As shown by bearophile, this shouldn't be assumed in the general case. I ran into an issue where std.parallelism assumed that opIndex was as cheap as popFront, but for my specific range it was easier to compute the next front knowing the previous one than it was to find the element given by the index. If these type of optimizations are important, perhaps there should be some "performance hint tags" for range operations. e.g. popFront on an array range is "cheap" whereas popFront on a MapResult may vary arbitrarily. --
