template statistics

[jmh530]

On Wednesday, 3 June 2020 at 11:22:23 UTC, Stefan Koch wrote:
> [snip]
> type functions are one way to make this happen.
> However changes to the language are hard justify therefore I am 
> currently revisiting,
> approaches to infer type-function-like behavior and transform 
> them behind the scenes.
> (Which is a HUGE pain, because you have to transform recursion 
> into loops, which is a hard problem in itself, AND the user 
> probably would rather have written a loop, but was forced by 
> the language to use recursion. )
> [snip]

I was just thinking about this again in light of Manu's recent 
post [1] on the bonus thread. Manu specifically mentions types 
not working well in static contexts like types and aliases.

It occurs to me that there may be a connection between what Manu 
said and the issue that DIP 1023 [2] attempted to resolve. For 
instance, consider the DIP example
alias PackedUpperTriangularMatrix(T) = Slice!(StairsIterator!(T*, 
"-"));
What if instead you have a function that takes a type and returns 
an alias to another type? Ignoring any issues with the syntax, it 
might look something like this
alias PackedUpperTriangularMatrix(T)() {
     return alias Slice!(StairsIterator!(T*, "-"));
}
and could be used like
auto foo(T)(PackedUpperTriangularMatrix!T m) { }
(which is the same as in the DIP).

At the end of the day, you would still need to ensure the 
compiler would actually resolve those types before the function 
is called. So I imagine that just adding the support to be able 
to do the first bit does not imply the second bit would work. 
However, the issue with the solution presented in DIP 1023 was 
that it was only designed to work with the short alias syntax and 
not the full template alias syntax, which may not have been 
possible and could have led to a special casing. This is a simple 
rule: resolve the type/alias functions first.

I know on other threads you have talked about how much work it 
would be to go further with type functions and you would need 
Walter's blessing and help. However, I think that if it means 
that we could get an alternative resolution to the issues brought 
up by DIP 1023, then I would be all on board (and willing to 
contribute to support the work).


[1] 
https://forum.dlang.org/post/mailman.3585.1591274099.31109.digitalmars-d@puremagic.com
[2] 
https://github.com/dlang/DIPs/blob/master/DIPs/other/DIP1023.md