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