On Tuesday, 6 May 2014 at 00:10:36 UTC, Andrei Alexandrescu wrote:
So I'm looking at creation functions and in particular creation functions for arrays.
I like Adam's input range idea. It gives you the best of both worlds, I think. It clears the conflict between ints and lengths using an interface.
1. Follow the new int[n] convention: auto a = allok.make!(int[])(42); assert(a.length == 42); assert(a.equal(repeat(0, 42));
auto a = allok.make(repeat(int.init).take(42)) A bit verbose but a shortcut could be added. I believe you may have proposed a second length argument to repeat before which would be nice and clean with UFCS, e.g., int.init.repeat(42).
2. Follow the [ literal ] convention: auto a = allok.make!(int[])(42); assert(a.length == 1); assert(a[0] == 42);
auto a = allok.make(42); // maybe require only() or don't use IFTI.
For the second option, to create longer arrays: auto a = allok.make!(int[])(42, 43, 44); assert(a.length == 3); assert(a.equal(iota(42, 45));
auto a = allok.make(iota(42, 45));
Nice ways to repeat things: auto a = allok.make!(int[])(42, repeat(43, 5), 44);
auto a = allok.make(42, repeat(43).take(5), 44); // recognize RoRs and expand them (or joiner() with only()
And even nice ways to create holes for efficiency: auto a = allok.make!(int[])(42, uninitialized(5), 44);
uninitialized would be useful. Maybe uninitialized!int.take(5) to keep with the theme though I haven't fully considered if that would penalize performance.
Destroy. Andrei
One last thought. If array() accepted a second argument for an allocator you could just use a lot of existing code and slap an allocator into that final argument on your UFCS chain. auto arr = iota(1, 5).joiner(only(7, 13)).array(allok);
