https://issues.dlang.org/show_bug.cgi?id=24892
--- Comment #5 from Jonathan M Davis <[email protected]> --- (In reply to Dennis from comment #4) > The first point about it providing new information is false, you can already > use std.traits.BaseClassesTuple to find parents. I did not realize that that existed (or more likely, I read through it at some point and then forgot about it), but looking it over, it's an incredibly convoluted solution if you just want to ask whether one class is the base class of another. So, yes, it does provide a solution, taking advantage of a form of is expression that I didn't realize existed, but it's a pretty complicated solution for the simple question. That being said, it should be possible to use that particular is expression in a different way to implement something like isDerivedFrom!(T, U), which would be much better than doing something like getting the list of base classes and then filtering on them, which is what you'd have to do with BaseClassesTuple. > Templates constraints should simply ask what they need, which brings me back > to the unaddressed question: What actual function do you need it for? It's > really hard to reason about handwavy scenarios. When you propose a new > feature, there should be at least one real, concrete use case for it. As I said, the ability to know whether one class is derived from another is a basic question of type introspection. I've seen it come up often enough over the years where someone asks how to do it, and they're told to use is(T : U), which as I said, works in many cases but is fundamentally flawed thanks to alias this. This kind of question seems as basic to me as asking whether a function is virtual or whether a type has a particular member. And I already gave an example of where if you need to wrap and replicate D types in another language, then you need to be able to introspect on pretty much everything about the type (including about its base classes). Type introspection is not just about template constraints. I brought it up, because is(T : U) is wrong, but it's what people are routinely told to do, and I was unaware of any alternative which didn't run afoul of alias this. From the sounds of it, it is at least possible to implement a sane Phobos trait that answers the question, though honestly, I would think that it's basic enough, and the way to do it with is expressions is convoluted enough, that it would make more sense to just have a __traits trait for it. But since there is actually a way to do it, it's certainly a valid argument that it's not worth adding a trait for it to the compiler, though I disagree based on how basic a question this is. Either way, we need to have a simple solution that we can point to rather than telling folks to use is(T : U), whether that's in __traits, or it's a trait of some kind in Phobos. --
