TypeFunction example: ImplictConvTargets
Meta
jared771 at gmail.com
Tue Oct 6 18:49:08 UTC 2020
On Tuesday, 6 October 2020 at 18:30:15 UTC, Steven Schveighoffer
wrote:
> On 10/6/20 2:09 PM, Adam D. Ruppe wrote:
>> Filter's guts can be:
>>
>> size_t[Args.length] keep;
>> size_t pos = 0;
>> foreach(idx, alias arg; Args)
>> if(Pred!arg) keep[pos++] = idx; // note idx,
>> not arg.
>> return makeResult(keep[0 .. pos]);
>>
>> In today's D. Again, *almost identical* to the typefunction
>> version, just using an index into the list instead of storing
>> the alias in the array directly.
>
> I think Filter is a much more apt example than the implicit
> targets.
>
> Not just because you can make it faster, but because with type
> functions, you should be able to actually *use filter*:
>
> return Args.filter!Pred.array;
>
> I mean, we have filter for a reason. You can easily write
> filter out into a loop, instead of using filter. But there it
> is, and it makes coding so much more pleasant. If the compiler
> and CTFE can be fast enough to make this pleasant (I'm not 100%
> convinced, but it looks promising), then I'm on board.
>
> With a Tuple, everything is immutable, and each change needs to
> go across a new template boundary. Even a loop is not really a
> loop.
Excellent point; the only reason Filter, staticSort, staticMap,
Reverse, Repeat, etc., etc. exist is because of the limitations
of working with AliasSeq. If type functions can allow us to
replace most of these uses with good old std.range/algorithm
code, that's a huge win in my book.
We have a big chance to go left when C++ went right and went
all-in on template metaprogramming. Let's leave templates to do
what they were designed for - genericizing structures and
algorithms, and leave the compile-time computation to CTFE + type
functions.
More information about the Digitalmars-d
mailing list