First life-signs of type functions

Q. Schroll qs.il.paperinik at gmail.com
Mon May 11 21:14:47 UTC 2020


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.


More information about the Digitalmars-d mailing list