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