Added Not, And, and Or to std.typetuple.

[jmdavis]

The provide negation, logical and, and logical or for eponymous
templates which resolve to boolean values.

[dnadlinger]

Should be extended to work on predicates which operate on aliases/values as well.

[alexrp]

I thought the convention was to use camelCase for templates that resolve to values and PascalCase for templates that resolve to types?

[dnadlinger]

@alexrp: The result of the proposed templates is another template (they are »higher-order predicates«), and thus it makes sense for them to be Pascal-cased.

I think the implementations are of And/Or are too limited for practical use, though, as they don't implement short cut evaluation. I will post another pull request with my implementations, an old version of which I proposed at the forums some time ago: https://gist.github.com/1191885#L131.

[jmdavis]

Should be extended to work on predicates which operate on aliases/values as well.

I believe that it'll work on them as long as the template that you pass to them works on them. I didn't make it work on functions like I did with Filter in pull# 688, because we already have std.functional.not, and if you're passing a predicate that's a function, you can use that - though we don't have and or or in std.functional, and now that I think on it, if you you're dealing with several levels of templates, you don't know whether it was an eponymous template or a function to begin with. So yeah, I probably should make it so that they work with functions as well.

I think the implementations are of And/Or are too limited for practical use, though, as they don't implement short cut evaluation.

You mean make it so that in Or, it doesn't evaluate Pred2!T if Pred1!T is true? That has the downside of making it possible to pass an invalid predicate for Pred2, and it won't be noticed unless Pred1 fails. Or I am I misunderstanding what you mean?

I will post another pull request with my implementations, which I proposed at the forums some time ago

If you have a better one, please post it. But I believe that I need Not to fix a bug in sdt.traits, which is why I've been working on this, and it seemed appropriate to do And and Or at the same time. Also, if we get Reduce done, I believe that between these changes (or your version of them) and pull# 688, we get all of the stuff from std.typelist which is useful with TypeTuples.

If it's going to take you a while to deal with creating a pull request, I can create one with your implementations if you point me to them (that link has Not but not And or Or).

[dnadlinger]

Hm, replying via mail seems to disable Markdown processing…

I believe that it'll work on them as long as the template that you
pass to them works on them.

No, because only types are accepted by the T parameter of the "returned"
templates.

You mean make it so that in Or, it doesn't evaluate Pred2!T if
Pred1!T is true? That has the downside of making it possible to
pass an invalid predicate for Pred2, and it won't be noticed unless
Pred1 fails. Or I am I misunderstanding what you mean?

Yes, I was indeed proposing that later predicates are not evaluated. But
I found that the possible disadvantages with regard to »invalid«
predicates are by far outweighed by the fact that the behavior allows
you to write code in a very natural way, similar to runtime code: For
example, just as in if (foo && foo.someProperty) { … }, evaluating
the second part on foo would segfault if foo was null in runtime code,
shortcut evaluation at compile time allows you to do things like
Filter!(All!(HasType, Compose(hasIndirections, TypeOf)), GetMembers!Foo), where TypeOf doesn't compile for things which don't
have types.

I found this to be quite helpful when working on the Thrift compile-time
codegen stuff (even if the parts where I made the most use of this never
saw the public). The alternative would often have been to wrapping the
whole, in some instances quite complex predicate with CompilesAndTrue,
where the potential for hiding errors would be much bigger.

/**
 * Wraps the passed template predicate so it returns true if it compiles and
 * evaluates to true, false it it doesn't compile or evaluates to false.
 */
template CompilesAndTrue(alias T) {
   template CompilesAndTrue(U...) {
     static if (is(typeof(T!U) : bool)) {
       enum bool CompilesAndTrue = T!U;
     } else {
       enum bool CompilesAndTrue = false;
     }
   }
}

If it's going to take you a while to deal with creating a pull
request, I can create one with your implementations if you point me to
them (that link has Not but not And or Or).

Any and All were my take on And and Or – if you give me a few
minutes, I'll put the stuff up for discussion, even if in a slightly
unpolished state.

[jmdavis]

No, because only types are accepted by the T parameter of the "returned" templates.

Hmm. Well, I tried using an alias there, and it wouldn't compile, so I went with T. Looking at your stuff though, you went with a variadic template argument. I guess that that fixes the problem then?

I'll put the stuff up for discussion, even if in a slightly unpolished state.

Okay. Thanks.

[jmdavis]

Any and All were my take on And and Or

I should have thought of making them work on more than two arguments (in which case Any and All do make more sense), but I was looking at what std.typelist did, and that just didn't occur to me. Shame on me.

[dnadlinger]

Okay, the pull request is up. Took me forever because I hit a nasty compiler bug in the unit tests, and tried to reduce it without success…

[jmdavis]

Okay. I'll close this one, since yours is clearly better, and if there are any issues with it, we can just adjust that code appropriately.