ES.63 ("Don't slice") not justifiable as stated and clashes with P.1 and P.3

[eyalroz]

Rule ES.63: Don't slice is worded very strongly and decisively. It claims slicing is (almost always) undesirable and inappropriate: In all contexts, for all purposes. The motivation given, however, is that this "most often leads to errors".

So, my first point is that the rule itself concedes that this does not always lead to errors; and that we (or the rule authors) do not have a general argument about an arbitrary slicing scenario leading to errors, in itself. That is, given class B : public A { /*...*/ } and result_type foo(A), I do not believe we can show that calling foo(some_B) is problematic, unless we make significant assumptions about A and B. And the rule can only stand when qualified by these assumptions.

The second point regards the expression of intent, rule P.3 (edit:) and rule P1, "express ideas directly in code".

When a programmer says class B : public A, they are saying that "An object of type B is, in particular, an object of type A - and can be treated as such" (in other words, the use of public inheritance implies, or strongly insinuates, that the Liskov Substitution Principle applies.) An object of type A can be passed to a function which takes a parameter of type A, by value. Claiming that slicing is essentially forbidden means that we must ignore the expressed intent of the public inheritance, or rather, than we use public inheritance despite not having its actual intent.

If slicing is problematic for some class B : public A, then - why should B publicly inherit A? The inheritance could be protected, or private. That way, the programmer actually tells the compiler (and other programmers) whether the A making up B can or can't be sliced. But - that's a bit of a facetious point: We know such a convention is not what most programmers use in practice - because of convenience. If you inherit private or protected, you have to explicitly make available each and every bit of A again in B, which is quite tedious. So, the lazy thing to do is to just inherit publicly and rely on people ignoring the public inheritance: "I know I said my B is an A, but, come on, don't take it seriously... pretend my class is mis-defined and be extra-careful yourself".

I am not suggesting, that the guidelines switch position entirely, and demand that everyone change the way they code, and only use protected and private inheritance when slicing is problematic. But - ES.63 as it stands essentially forces people to adopt a broken interpretation of public inheritance - to ignore the expressed intent.

For these two reasons, I claim that the guideline should be relaxed from "don't slice" to something like "carefully consider the legitimacy of slicing" (this doesn't have to be the exact phrasing of course); and that the rule mention the potential pitfalls explicitly, but also remind readers about the meaning of public inheritance, suggesting that they also consider the possibility of private/protected inheritance if they are the class authors. The cases of zero-size / no-data-members objects can then be mentioned more briefly as an example of a legitimate use of slicing.

[jwakely]

You need to provide concrete examples where it is useful and correct to slice in ways that are not allowed by the current rule.

[eyalroz]

You need to provide concrete examples where it is useful and correct to slice in ways that are not allowed by the current rule.

No, it's the other way around. Slicing is explicitly allowed by the language, and intended behavior when publicly inheriting another class. To forbid it outright, the rule authors/maintainers of the guidelines need to prove there it cannot be useful and correct to slice.

Still, if you want some examples: Subclasses with mixins in addition to the 'main' parent class, which introduce extra info, like a name field or provenance information.

I should also mention, that legitimate slicing is mostly relevant to types which are small. Otherwise, even without the slicing, taking arguments by value is usually undesirable, since it couples the copying with whatever other action a function is intended to carry out. e.g. a do_stuff(ClassContainingAnStdVector obj) is typically a bug, whether you pass it the actual class or a subclass. In fact, I would think slicing would be particularly relevant in functions which take reference-type values, by value. So, subclasses of string_view's, or of span's, and such.

[jwakely]

You need to provide concrete examples where it is useful and correct to slice in ways that are not allowed by the current rule.

No, it's the other way around. Slicing is explicitly allowed by the language, and intended behavior when publicly inheriting another class. To forbid it outright, the rule authors/maintainers of the guidelines need to prove there it cannot be useful and correct to slice.

By that logic most of the guidelines would not exist. Lots of things the language allows are not recommended.

Still, if you want some examples: Subclasses with mixins in addition to the 'main' parent class, which introduce extra info, like a name field or provenance information.

Why is it a good idea to use public inheritance and permit slicing?

I should also mention, that legitimate slicing is mostly relevant to types which are small. Otherwise, even without the slicing, taking arguments by value is usually undesirable, since it couples the copying with whatever other action a function is intended to carry out. e.g. a do_stuff(ClassContainingAnStdVector obj) is typically a bug, whether you pass it the actual class or a subclass. In fact, I would think slicing would be particularly relevant in functions which take reference-type values, by value. So, subclasses of string_view's, or of span's, and such.

Why is it better to derive publicly from those view types instead of providing an accessor function that returns the view?

[eyalroz]

You need to provide concrete examples where it is useful and correct to slice in ways that are not allowed by the current rule.
By that logic most of the guidelines would not exist.

I believe that is not the case, because few guidelines are decisive and absolute: "Don't slice". Take, for example, a rule like like: R.11 Avoid calling new and delete explicitly. The rule does not say "Do not call new and delete"; it does not even say "Don't call new and delete explicitly". It says "avoid", which is a weaker phrase; and it has the wide exception or loophole of "directly". And that is why my suggestion is to relax this rule, not remove it entirely.

To be clear, I believe the admonition against slicing should be weaker still, i.e. a warning about the detriments rather than an "avoid" suggestion. But it's true that for relaxing the rule between these two levels, it is on me to make an argument about use-cases etc.

Lots of things the language allows are not recommended.

... but few things in the language are forbidden.

Why is it a good idea to use public inheritance and permit slicing?

Well, if:

1. Objects of class B are, in particular, objects of class A, and that fact is not just an implementation detail but a fundamental aspect of them;
2. We have a function f() taking A's by value, but not a function doing the same thing and taking B's (e.g. because it's not templated, or there is no template implementation for B's)

then - it would be a shame if we were not to call f() on our B's, when they are perfectly good A's. That's what f() was written for. And it would be rather silly if we would refrain from calling f() on B's not because it's impossible, but because of the guidelines.

Now I guess you might tell me:

• "It might not be safe to use (a copy of) the A inside of a B - it might undermine the B instance invariants" - but that means the author of B was either wrong or careless in making the inheritence public. That might justify qualifying the legitimacy of permitting slicing with a demand of care, or abundance-of-caution, or whatever.
• "Why does f() take the A by value anyway? Just avoid this whole problem by taking an A& or const A&" - that is sometimes decent advice; but very often - it is not, as it contradicts two other guidelines:
  • F.15: Prefer simple and conventional ways of passing information
  • F.16: For "in" parameters, pass cheaply-copied types by value and others by reference to const
    A is an in-parameter of f(), and it's received by value because it's cheap to copy, and semantically, f() does not want nor need the linkage to the original location of the A - it only wants its value.
• "Why not have template <SomeConcept T> FRetVal f(T) then?" - because it might be over-generalization to have written f() like that in the first place; or f() is implemented in a compiled library, i.e. you get the declaration and the object, and can't just instantiate it differently. Plus, it's possible that it's actually not so desirable to copy B, although that might be somewhat of a corner case.

Why is it better to derive publicly from those view types instead of providing an accessor function that returns the view?

Because that would warp the semantics. If you have a class which is, say, a named span, then - it is, in particular, a span. We should not pretend that it's not a span and have it so that you can only get a span from it by invoking some method. The named span is-a span, and we should P.1: Express ideas directly in code. Also, as I was saying earlier, our code should P.3: Express intent - and avoiding the named span inheriting the span express the opposite of intent.