API

[Brad Anderson via Digitalmars-d]

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);