First life-signs of type functions

[Stefan Koch]

On Monday, 11 May 2020 at 21:14:47 UTC, Q. Schroll wrote:
> On Sunday, 10 May 2020 at 10:45:54 UTC, Nick Treleaven wrote:
>> On Sunday, 10 May 2020 at 10:33:42 UTC, Stefan Koch wrote:
>>> What do you think about this one?
>>>
>>> bool anySatisfy(bool function (alias) pred, alias[] types ...)
>>> {
>>>     foreach(type; types)
>>>     {
>>>         if (pred(type))
>>>             return true;
>>>     }
>>>     return false;
>>> }
>>
>> Nice, this makes me wonder if later we'll get type function 
>> lambdas :-D
>
> That would be massive.
>
> struct S(Ts...)
> {
>      Ts values;
>
>      bool opCmp()(S!Ts other)
>      if (allSatisfy!((alias T) => is(typeof(T.init < T.init)), 
> Ts))
>      { /* implementation */ }
> }
>
> I wonder if it there's value in not only having aliases as 
> parameters but also specifying types and values in particular. 
> An alias is an unrestricted compile-time name (ctName), so why 
> not have the "subtypes" ctType and ctValue of ctName? That way, 
> a "type function" would signal: That parameter is supposed to 
> be (the alias of) a type, this other one (the alias of) a 
> value. It wouldn't add any power, with this, you can do 
> is(name) and is(typeof(name)) already to find out if `name` is 
> an alias of a type or value respectively.

In a type function alias cannot bind to values at all.
It can only bind to symbols or types.
If you want to pass values in you have to use the appropriate 
parameter type.
Which just like in regular functions has to be something the 
argument can convert to.
all types can implicitly convert to alias, which is a regular 
type.
and signifies that the variable holds types or symbols.