>From: "Terje Slettebų" <[EMAIL PROTECTED]> > Given that supertype/subtype has such a general meaning, how should an > is_super_and_subtype be defined? I guess the proposal mean to define it in > terms of inheritance, only, and in that case, it would work like > is_base_and_derived, with the addition that a type is its own > supertype/subtype (but not its own base/derived type).
If we consider substitutability outside the class hierarchy, only (not considering private/protected inheritance), then for is_super_and_subtype to obey LSP, it should only give true in the case where an object or pointer/reference of a type S is implicitly convertible to type T. This means public, unambiguous base class, only. This is the way is_base_and_derived works today, except that it doesn't give true for B = D. However, for is_base_and_derived to really tell if something is base and derived classes, it should ignore issues of access and ambiguity, which is related to convertibility/substitutability, only, but not to whether or not they are related by inheritance. In other words, it should give the semantic that Rani's proposal has. Whether or not the above semantic is desirable is another question. However, if it is, to summarise, we could define these like this: - Rename the current is_base_and_derived to is_super_and_subtype, and allow it to give true for S = T. - Use Rani's proposal for the new is_base_and_derived. Add specialisation to give false for B = D. There's also a question of existing code relying on the current semantics, of is_base_and_derived giving false in the case of private/protected or ambiguous base class. However, it may be argued that such code does not rely on the stated documentation, so it's broken, anyway. Changing the implementation of is_base_and_derived to use Rani's proposal still gives its stated semantics, which is (from the docs): is_base_and_derived<T,U>::value - Evaluates to true if type T is a base class to type U. It does not say "public, unambiguous base". That could be the wording for is_super_and_subtype, instead. Regards, Terje _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
