[Issue 9582] std.algorithm.map!(T) cause CT error for fixed size arrays

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=9582



--- Comment #9 from bearophile_hugs at eml.cc 2013-02-24 14:40:31 PST ---
(In reply to comment #8)

> Can you elaborate on the "why" though? Is it just because it would be "breaking
> change", or do you have a use case that warrants its being in there in the
> first place (more so than any algorithm I mean)?

I have a good amount of functional-style D2 code with hundreds of usages of
reduce. And in D I use fixed-sized arrays all the time to reduce heap activity,
so probably this change will require me some fixes in my code, to add the [].

I don't like this change in principle, because I like fixed-size arrays, I use
them all the time, and I think they should be more first class in Phobos. I'd
like more Phobos functions to work with fixed size arrays, not less functions.

Also, reduce() doesn't return part of the input, it creates a new output, so it
the code that uses the result of reduce() doesn't need to care what reduce()
was fed with. The same is true for array(). I think reduce() and array() should
also work on opApply, for maximum flexibility.

The higher order functions of my D1 nonstandard library accepted both kinds of
arrays, and even associative arrays as inputs. I prefer more flexibility. And I
think that forcing everything inside the mindframe of Ranges is a not a good
idea. Iteration life is more complex:
http://journal.stuffwithstuff.com/2013/01/13/iteration-inside-and-out/

In past I have asked one small changes in Phobos that was closed down because
despite it being handy and useful, it was a small breaking change. Forbidding
fixed size arrays as reduce inputs _reduces_ flexibility, and it's a larger
breaking change.

In the end I am probably able to add the missing [] to my D2 code in a matter
of one or two hours (or less) so for me this change doesn't require me a lot of
work to fix. So I leave the decision to you.

---------------

> Static arrays, while being iterable, shouldn't be passed around by
value to functions. I think there'd be gains in the long run to such a scheme.<

Let's say I have this fixed-sized array:

int[3] items = [1, 2, 3];

and I want to compute its sum:

reduce!q{a + b}(items)

In this case ideally I'd like the D compiler to replace that call to reduce
with the same ASM as 

items[0] + items[1] + items[2]

This means the compiler has some compile-time information (the array length)
that in theory (and in practice too if the code is well written and you are
using a GCC back-end that is able to unroll small loops) is usable to produce
full optimized code.

If I have to write:

reduce!q{a + b}(items[])

Then we have lost something, the reduce() can't know at compile-time the length
of the array, so performing loop unrolling becomes harder (the JavaVM is able
to partially unroll the loop in this case too, but LLVM was not able to do it
since the latest version, and even now it's not perfect).

Throwing away some compile-time information seems a bad idea to me.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------