Add AliasSeqOf to std.meta

[jcrapuchettes]

Add template that allows for conversion of arrays and input ranges to AliasSeqs.

[Hackerpilot]

✅

[Hackerpilot]

Context:
#3369
#1472

[JakobOvrum]

PR #1472 had an optimization that yields less template instantiations for arrays, which is something that actually can be applied to all ranges with length and slicing. Would this be worth adding?

edit:

The result cannot contain types; the name shouldn't be capitalized.

[dnadlinger]

It might make sense compile time-wise to transform all other ranges to arrays first using CTFE (array), and only then going into the template part (O(N) vs. O(1) instantiations).

[atilaneves]

Why the call to array if AliasSeqOf takes any input range?

[jcrapuchettes]

Good question and I've now removed it.

[jcrapuchettes]

After evaluating the initial implementation and the implementation from #1472, I found that the #1472 was significantly better. It was able to handle ranges and arrays greater than 250 elements. To that end, I've copied the implementation from #1472, modified it a little, and copied in its unit tests.

Thanks to @monarchdodra!

[JakobOvrum]

Nitpick: I and V will never refer to types, so they should not be capitalized.

[JakobOvrum]

LGTM. I would have preferred toAliasSeq but I'm fine with the current name too.

[Hackerpilot]

Auto-merge toggled on

[monarchdodra]

Awesome!

I guess I don't get a say in this anymore, but if I had to write my original implementation again, I'd only implement support for arrays. std.meta should not have a dependency on std.range, as range is more of a library concept than language concept (and meta is more of a language support module). That and having the caller do aliasSeqOf!(myRange.array()) is trivially easy.

I'm not sure how much we are still trying to untangle library dependencies?

[JakobOvrum]

@monarchdodra, good point, I agree it's better to leave the conversion to array to the caller. Maybe file a PR? I don't think this is part of the new release.