TypeFunction example: ImplictConvTargets

[Paul Backus]

On Tuesday, 6 October 2020 at 23:44:30 UTC, Stefan Koch wrote:
> On Tuesday, 6 October 2020 at 23:36:00 UTC, Paul Backus wrote:
>>
>> 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.

I agree that allowing completely unrestricted tuple mutation 
would be problematic, but I think it's still worth asking how far 
we could potentially go in that direction.

For example, maybe you're only allowed to mutate tuples inside 
the scope that declares them. That would let you implement 
templates like Filter and staticMap iteratively, while still 
presenting an immutable "interface" to the rest of the program.