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.
>
> 1. Follow the new int[n] convention:
>
> auto a = allok.make!(int[])(42);
> assert(a.length == 42);
> assert(a.equal(repeat(0, 42));
>
> 2. Follow the [ literal ] convention:
>
> auto a = allok.make!(int[])(42);
> assert(a.length == 1);
> assert(a[0] == 42);
>
> 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));
>
> Nice ways to repeat things:
>
> auto a = allok.make!(int[])(42, repeat(43, 5), 44);
>
> And even nice ways to create holes for efficiency:
>
> auto a = allok.make!(int[])(42, uninitialized(5), 44);
>
>
> Destroy.
>
> Andrei

The first option should have better performance(write fast code). The second method allows more expressiveness(write code fast). I generally like expressiveness, but direct memory allocation is low level programming, so fast code should take precedence.

On 5/5/2014 5:10 PM, Andrei Alexandrescu wrote:
> So I'm looking at creation functions and in particular creation functions for
> arrays.

My bikeshed color comments:

1. "allok" is too kute for a name. Rather have "allocate" or "alloc".

2. why "make" instead of "construct" or "factory"?

On Tuesday, 6 May 2014 at 00:54:33 UTC, Walter Bright wrote:
> On 5/5/2014 5:10 PM, Andrei Alexandrescu wrote:
>> So I'm looking at creation functions and in particular creation functions for
>> arrays.
>
> My bikeshed color comments:

> 2. why "make" instead of "construct" or "factory"?

Or "build" ?

Matheus.

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

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.
>
> 1. Follow the new int[n] convention:
>
> auto a = allok.make!(int[])(42);
> assert(a.length == 42);
> assert(a.equal(repeat(0, 42));
>
> 2. Follow the [ literal ] convention:
>
> auto a = allok.make!(int[])(42);
> assert(a.length == 1);
> assert(a[0] == 42);
>
> 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));
>
> Nice ways to repeat things:
>
> auto a = allok.make!(int[])(42, repeat(43, 5), 44);
>
> And even nice ways to create holes for efficiency:
>
> auto a = allok.make!(int[])(42, uninitialized(5), 44);
>
>
> Destroy.
>
> Andrei

Does it have to be one function?

allok.makeLength!(int[])(42) as per new int[n] convention
allok.makeUsing!(int[])(42, 43, 44) as per literal convention



s/makeUsing/makeFilled -- or just makeFill
s/makeUsing/makeFrom
s/makeUsing/makeWith

etc. etc.

Cheers,
Ed

On 5/5/14, 5:54 PM, Walter Bright wrote:
> On 5/5/2014 5:10 PM, Andrei Alexandrescu wrote:
>> So I'm looking at creation functions and in particular creation
>> functions for
>> arrays.
>
> My bikeshed color comments:
>
> 1. "allok" is too kute for a name. Rather have "allocate" or "alloc".

Fortunately that's not part of the API, just of the example.

> 2. why "make" instead of "construct" or "factory"?

Shorter.


Andrei

On 5/5/2014 7:51 PM, Andrei Alexandrescu wrote:
> On 5/5/14, 5:54 PM, Walter Bright wrote:
>> 2. why "make" instead of "construct" or "factory"?
> Shorter.

"Less" is 4 characters. I win!

On 5/5/14, 9:56 PM, Walter Bright wrote:
> On 5/5/2014 7:51 PM, Andrei Alexandrescu wrote:
>> On 5/5/14, 5:54 PM, Walter Bright wrote:
>>> 2. why "make" instead of "construct" or "factory"?
>> Shorter.
>
> "Less" is 4 characters. I win!

Semantics suk. -- Andrei

Brad Anderson:

> 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.

I don't like it a lot. I think I'd like two differently named functions. I am not sure.


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

This is a nice idea. What about std.array.uninitializedArray and std.array.minimallyInitializedArray?

Bye,
bearophile

On 5/5/14, Adam D. Ruppe via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Tuesday, 6 May 2014 at 00:10:36 UTC, Andrei Alexandrescu wrote:
>> 1. Follow the new int[n] convention:
>> 2. Follow the [ literal ] convention:
>
> We could combine these pretty easily:
>
> struct Length { size_t length; }
>
> allok.make!(int[])(Length(42)); // #1
> allok.make!(int[])(1,2,3); // #2 btw could also use IFTI here
> which is nice
>
> This also potentially gives a third option:
>
> allok.make!(Length(42), 5); // length == 42, all elements == 5,
> typeof(return) == typeof(args[1])[]
>
>
> I kinda like that, though I'm not sure if I'd still like it if I used it regularly. Then, of course, we can also take other ranges to initialize too.
>

I actually think this is a very elegant solution, but does open the question, should `allok.make!(42)` create an array initialized to 42, or an array with length of 42? Provided this is documented, I don't think the ambiguity should be an issue.