TypeFunction example: ImplictConvTargets

Stefan Koch uplink.coder at googlemail.com
Tue Oct 6 23:44:30 UTC 2020


On Tuesday, 6 October 2020 at 23:36:00 UTC, Paul Backus wrote:
> On Tuesday, 6 October 2020 at 18:30:15 UTC, Steven 
> Schveighoffer wrote:
>> It comes down to one thing -- arrays vs. tuples. In type 
>> functions, a tuple is an array, and you can do all the things 
>> you can do with a normal array: mutate, sort, shrink, grow, 
>> loop, use as a range, etc.
>>
>> 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.
>
> It seems to me like maybe the most obvious way from point A to 
> point B is to lift these limitations on tuples (and aliases, 
> and manifest constants). Then we could write, for example:
>
> template Filter(alias pred, Args...)
> {
>     enum pos = 0;
>     foreach (Arg; Args) {
>         static if (Pred!Arg) {
>             Args[pos] := Arg;
>             pos := pos + 1;
>         }
>     }
>     alias Filter = Args[0 .. pos];
> }
>
> You would still pay for the performance overhead of tuple 
> foreach and static if, so maybe it's not that big a win, but 
> it's still an improvement over recursive templates and 
> CTFE+mixins.

I think lifting limitations on tuples can't be done in general 
without violation of current language rules.
Type functions are actually just a shell around operations that 
would be illegal in the language as is.
But because the type function provides a boundary I can do these 
things without invalidating the language semantics.

Type functions are something which can be proven to not have 
influence on language semantics outside of their own function 
bodies.


More information about the Digitalmars-d mailing list