On Saturday, 20 December 2014 at 00:15:21 UTC, MarcelDuchamp
wrote:
> You've forget the array of ref version. (append the address of the first data)

What "array of ref" version? Sounds like it would be a different
data structure, which would be beyond the scope the topic.

> And adding S to an array is biased. S is fucking only >>8<< bytes. add more data to your struct.

Adding a hundred more bytes to S didn't change the relative
outcome for me. At a thousand more bytes the second version
(appending an array literal) faints, and the others are closer
together, but the relative order stays the same.

On Thursday, 18 December 2014 at 20:12:01 UTC, Tobias Pankrath wrote:
> You shouldn't use my code verbatim though. For example, you should only use x.length, if x is of element type of data. Otherwise if you have e.g. an array of array you'd get totally wrong numbers.

What role does `x` play here? Does it mean the range `data` or the `args` to be appended?

See my update at

https://github.com/nordlow/justd/blob/master/algorithm_ex.d#L1602

which tries to merge all the ideas into one adapting algorithm :)

Destroy!

On Friday, 26 December 2014 at 16:29:56 UTC, Nordlöw wrote:
> See my update at
>
> https://github.com/nordlow/justd/blob/master/algorithm_ex.d#L1602
>
> which tries to merge all the ideas into one adapting algorithm :)
>
> Destroy!

BTW:

1. Is is relevant to extend `append` to data being a non-Random-Access range?
2. I guess a corresponding `prepend` is motivated aswell, right?

On Friday, 26 December 2014 at 16:31:48 UTC, Nordlöw wrote:
> On Friday, 26 December 2014 at 16:29:56 UTC, Nordlöw wrote:
>> See my update at
>>
>> https://github.com/nordlow/justd/blob/master/algorithm_ex.d#L1602
>>
>> which tries to merge all the ideas into one adapting algorithm :)
>>
>> Destroy!
>
> BTW:

writeln(estimateLength([1,2,3],[1,2,3]));

If appending to an int[] this must print 6, if appending to an
int[][] it should
print 2.


> 1. Is is relevant to extend `append` to data being a non-Random-Access range?

Currently it does not work for RA ranges, only for arrays. RA
ranges cannot grow and std.container.Array is no RA range.

> 2. I guess a corresponding `prepend` is motivated aswell, right?

Maybe not, since you cannot efficiently prepend to an array, so
having users call bringToFront explicitly might be more inline
with how e.g. std.container handles complexities.

On Saturday, 27 December 2014 at 07:34:43 UTC, Tobias Pankrath wrote:
> On Friday, 26 December 2014 at 16:31:48 UTC, Nordlöw wrote:
>> On Friday, 26 December 2014 at 16:29:56 UTC, Nordlöw wrote:
>>> See my update at
>>>
>>> https://github.com/nordlow/justd/blob/master/algorithm_ex.d#L1602
>>>
>>> which tries to merge all the ideas into one adapting algorithm :)
>>>
>>> Destroy!
>>
>> BTW:
>
> writeln(estimateLength([1,2,3],[1,2,3]));
>
> If appending to an int[] this must print 6, if appending to an
> int[][] it should
> print 2.

Do you have a suitable proposal for a CT-expression that checks if an argument of type E to estimateLength() will be treated as T[] in the append?

My current suggestion is

    isArray!A && is(T == ElementType!(A)) && hasLength!A

in use at

https://github.com/nordlow/justd/blob/master/algorithm_ex.d#L1602

with the hope of being compatible with static arrays.

However uncommenting

https://github.com/nordlow/justd/blob/master/algorithm_ex.d#L1680

gives compilation error as

algorithm_ex.d(1658,20): Error: template std.array.Appender!(int[]).Appender.put cannot deduce function from argument types !()(int[3]), candidates are:
/home/per/opt/x86_64-unknown-linux-gnu/dmd/linux/bin64/src/phobos/std/array.d(2518,10):        std.array.Appender!(int[]).Appender.put(U)(U item) if (canPutItem!U)
/home/per/opt/x86_64-unknown-linux-gnu/dmd/linux/bin64/src/phobos/std/array.d(2554,10):        std.array.Appender!(int[]).Appender.put(Range)(Range items) if (canPutConstRange!Range)
/home/per/opt/x86_64-unknown-linux-gnu/dmd/linux/bin64/src/phobos/std/array.d(2563,10):        std.array.Appender!(int[]).Appender.put(Range)(Range items) if (canPutRange!Range)
algorithm_ex.d(1658,20): Error: template std.array.Appender!(int[]).Appender.put cannot deduce function from argument types !()(int[3]), candidates are:
/home/per/opt/x86_64-unknown-linux-gnu/dmd/linux/bin64/src/phobos/std/array.d(2518,10):        std.array.Appender!(int[]).Appender.put(U)(U item) if (canPutItem!U)
/home/per/opt/x86_64-unknown-linux-gnu/dmd/linux/bin64/src/phobos/std/array.d(2554,10):        std.array.Appender!(int[]).Appender.put(Range)(Range items) if (canPutConstRange!Range)
/home/per/opt/x86_64-unknown-linux-gnu/dmd/linux/bin64/src/phobos/std/array.d(2563,10):        std.array.Appender!(int[]).Appender.put(Range)(Range items) if (canPutRange!Range)
algorithm_ex.d(1681,16): Error: template instance algorithm_ex.append!(int, int[3], int[3]) error instantiating

Comint exited abnormally with code 1 at Tue Dec 30 23:55:33

Isn't appender compatible with static arrays?

On Friday, 26 December 2014 at 16:31:48 UTC, Nordlöw wrote:
> On Friday, 26 December 2014 at 16:29:56 UTC, Nordlöw wrote:
>> See my update at
>>
>> https://github.com/nordlow/justd/blob/master/algorithm_ex.d#L1602
>>
>> which tries to merge all the ideas into one adapting algorithm :)
>>
>> Destroy!
>
> BTW:
>
> 1. Is is relevant to extend `append` to data being a non-Random-Access range?
> 2. I guess a corresponding `prepend` is motivated aswell, right?

Append and Prepend would be very useful additions to Phobos it's
quite surprising there not already there? In any case would love
to see some pull requests :)

On Wednesday, 31 December 2014 at 00:36:36 UTC, Damian wrote:
> Append and Prepend would be very useful additions to Phobos it's
> quite surprising there not already there? In any case would love
> to see some pull requests :)

Do we really need Append and Prepend (along with append and prepend) here? Doesn't [cC]hain already fulfill the needs of a lazy range in this case inplace of Append?

/Per