**No, it's not required:** Bjarne Stroustrup, [explained][1] how he naively added `protected` to C++ release 1.2, thinking to provide a useful feature to class developers, just to conclude only 5 years later that it was a nasty source of bugs, that fortunately no one was forced to use. Nowadays, he [recommends not to use it][2]. The **practical arguments** against `protected` are the advantages of stronger encapsulation and the [principle of the least knowledge][3]: * Either a member is `public` and can be used by anybody; * Or the member is `private` and needs to be protected against external access. * A `protected` member, that requires careful usage (otherwise it would be public) can be misused as much by insiders (developers of derived class) as by anybody else. **Formal arguments** confirm the practical experience. This has to do with the [Liskov Substitution principle][4] and more precisely its *history rule*: > We think it ought to be sufficient for a user to only know about the > “apparent” type of the object; the subtype ought to preserve any > properties that can be proved about the supertype.<br/> > - Barbara Liskov & Jeanette Wing in [*A behavioral notion of subtyping*][5] Without going into the details of the quoted article, the protected members allow a derived class (subtype) to change the state of the base class object (supertype) in an unexpected manner, without relying on its public operations. This being said, beware of the **appearances** and false promises. The Swift `private` is in-between `private` and `protected` in other languages: > Private access restricts the use of an entity to the enclosing > declaration, **and to extensions of that declaration that are in the > same file**. (...).<br/> > - Apple, in *[The swift programming language][6]* [1]: http://www.stroustrup.com/dne.html [2]: https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rh-protected [3]: https://en.wikipedia.org/wiki/Law_of_Demeter [4]: https://en.wikipedia.org/wiki/Liskov_substitution_principle [5]: https://dl.acm.org/citation.cfm?doid=197320.197383 [6]: https://docs.swift.org/swift-book/LanguageGuide/AccessControl.html