Is there a generic way to do


typeof(fn(E.init))[] map1(alias fn, E, size_t n)(E[n] container)
{
  import std.algorithm.iteration : map;
  import std.array : array;
  return container[].map!fn.array;
}

@safe pure nothrow unittest
{
  int[42] c;
  auto result = map1!(_ => _^2)(c);
}


but with propagation of length of return value of `f` to a static array instead, without having to specialize each range separately?

One less elegant way would be to replace the call to `array` with an overload of `std.container.util.make` for static arrays, that checks at run-time that the length of the output static array matches the length of the input range?

On Wednesday, 19 October 2016 at 13:59:29 UTC, Nordlöw wrote:
> Is there a generic way to do
>
>
> typeof(fn(E.init))[] map1(alias fn, E, size_t n)(E[n] container)
> {
>   import std.algorithm.iteration : map;
>   import std.array : array;
>   return container[].map!fn.array;
> }
>
> @safe pure nothrow unittest
> {
>   int[42] c;
>   auto result = map1!(_ => _^2)(c);
> }
>
>
> but with propagation of length of return value of `f` to a static array instead, without having to specialize each range separately?
>
> One less elegant way would be to replace the call to `array` with an overload of `std.container.util.make` for static arrays, that checks at run-time that the length of the output static array matches the length of the input range?

Couldn't you do this? Mind you I'm not able to test the code right now, but I think it can work with some tweaking.

typeof(fn(E.init))[n] map1(alias fn, E, size_t n)(E[n] container)
{
    import std.algorithm.iteration : map;
    import std.array : array;

    typeof(return) sres;
    return container[].map!fn.copy(sres[]);
}

@safe pure nothrow unittest
{
   int[42] c;
   //result should be a static array of length 42
   auto result = map1!(_ => _^2)(c);
}

On Wednesday, 19 October 2016 at 18:56:35 UTC, Meta wrote:
> Couldn't you do this? Mind you I'm not able to test the code right now, but I think it can work with some tweaking.
>
> typeof(fn(E.init))[n] map1(alias fn, E, size_t n)(E[n] container)
> {
>     import std.algorithm.iteration : map;
>     import std.array : array;
>
>     typeof(return) sres;
>     return container[].map!fn.copy(sres[]);
> }
>
> @safe pure nothrow unittest
> {
>    int[42] c;
>    //result should be a static array of length 42
>    auto result = map1!(_ => _^2)(c);
> }

Sorry, that code had a few mistakes. The working code:

import std.algorithm;
import std.range;

typeof(fn(E.init))[n] map1(alias fn, E, size_t n)(E[n] container)
{
    import std.algorithm.iteration : map;
    import std.array : array;

    typeof(return) sres;
    container[].map!fn.copy(sres[]);
    return sres;
}

void main()
{
   int[42] c;
   //result should be a static array of length 42
   auto result = map1!(_ => _^2)(c);
   assert(is(typeof(result) == typeof(c)));
}

https://goo.gl/t9m3YK

I'm actually pretty impressed that this kind of code can be written in D.

On Wednesday, 19 October 2016 at 19:01:50 UTC, Meta wrote:
> https://goo.gl/t9m3YK
>
> I'm actually pretty impressed that this kind of code can be written in D.

Thanks! Add at

https://github.com/nordlow/phobos-next/blob/master/src/algorithm_ex.d#L2234

On Wednesday, 19 October 2016 at 19:39:46 UTC, Nordlöw wrote:
> On Wednesday, 19 October 2016 at 19:01:50 UTC, Meta wrote:
>> https://goo.gl/t9m3YK
>>
>> I'm actually pretty impressed that this kind of code can be written in D.
>
> Thanks! Add at
>
> https://github.com/nordlow/phobos-next/blob/master/src/algorithm_ex.d#L2234

I would add this: not sure if it's what you're intending or not, but as `in` expands to `const scope` and the semantics of scope will probably be changing soon (or more accurately, actually implemented), you may want to just go with `const` instead.

On Wednesday, 19 October 2016 at 20:10:04 UTC, Meta wrote:
>> Thanks! Add at
>>
>> https://github.com/nordlow/phobos-next/blob/master/src/algorithm_ex.d#L2234
>
> I would add this: not sure if it's what you're intending or not, but as `in` expands to `const scope` and the semantics of scope will probably be changing soon (or more accurately, actually implemented), you may want to just go with `const` instead.

Ok, thanks. I updated.

On Wednesday, 19 October 2016 at 20:13:15 UTC, Nordlöw wrote:
> On Wednesday, 19 October 2016 at 20:10:04 UTC, Meta wrote:
>>> Thanks! Add at
>>>
>>> https://github.com/nordlow/phobos-next/blob/master/src/algorithm_ex.d#L2234
>>
>> I would add this: not sure if it's what you're intending or not, but as `in` expands to `const scope` and the semantics of scope will probably be changing soon (or more accurately, actually implemented), you may want to just go with `const` instead.
>
> Ok, thanks. I updated.

BTW: So what about const ref? Will this differ to `in` with regards to `scope`? If so will the compiler(s) be smart enough to not copy the large stack array when I only qualify with `const`?

On Wednesday, 19 October 2016 at 20:15:14 UTC, Nordlöw wrote:
> On Wednesday, 19 October 2016 at 20:13:15 UTC, Nordlöw wrote:
>> On Wednesday, 19 October 2016 at 20:10:04 UTC, Meta wrote:
>>>> Thanks! Add at
>>>>
>>>> https://github.com/nordlow/phobos-next/blob/master/src/algorithm_ex.d#L2234
>>>
>>> I would add this: not sure if it's what you're intending or not, but as `in` expands to `const scope` and the semantics of scope will probably be changing soon (or more accurately, actually implemented), you may want to just go with `const` instead.
>>
>> Ok, thanks. I updated.
>
> BTW: So what about const ref? Will this differ to `in` with regards to `scope`? If so will the compiler(s) be smart enough to not copy the large stack array when I only qualify with `const`?

Well, scope does not imply ref so in both cases a copy will be made.

On Wednesday, 19 October 2016 at 19:39:46 UTC, Nordlöw wrote:
> On Wednesday, 19 October 2016 at 19:01:50 UTC, Meta wrote:
>> https://goo.gl/t9m3YK
>>
>> I'm actually pretty impressed that this kind of code can be written in D.
>
> Thanks! Add at
>
> https://github.com/nordlow/phobos-next/blob/master/src/algorithm_ex.d#L2234

Made it even modular by factoring out arrayN at

https://github.com/nordlow/phobos-next/blob/master/src/algorithm_ex.d#L2200

and used at

https://github.com/nordlow/phobos-next/blob/master/src/algorithm_ex.d#L2215

Code:


ElementType!R[n] arrayN(size_t n, R)(R r)
{
    assert(r.length == n);
    typeof(return) dst;
    import std.algorithm.mutation : copy;
    r.copy(dst[]);
    return dst;
}

typeof(fun(E.init))[n] map(alias fun, E, size_t n)(const E[n] src)
{
    import std.algorithm.iteration : map;
    return src[].map!fun.arrayN!n;
}

@safe pure nothrow unittest
{
    import std.meta : AliasSeq;
    foreach (E; AliasSeq!(int, double))
    {
        enum n = 42;
        E[n] c;
        const result = map!(_ => _^^2)(c);
        static assert(c.length == result.length);
        static assert(is(typeof(result) == const(E)[n]));
    }
}

On Thursday, 20 October 2016 at 12:38:40 UTC, Nordlöw wrote:
> ElementType!R[n] arrayN(size_t n, R)(R r)
> {
>     assert(r.length == n);
>     typeof(return) dst;
>     import std.algorithm.mutation : copy;
>     r.copy(dst[]);
>     return dst;
> }

Is there a place for part of this logic in Phobos?

I'm thinking perhaps array{N,Exactly} should be added to std.array.

The idea came to me after learning about dependent types in Idris:

http://www.idris-lang.org/