On Tuesday, 19 December 2023 16:33:36 -03 Jason McKesson via Std-Proposals
wrote:
> > 'private' and 'protected' are useful, in particular when it comes to
> > SFINAE.
> >
> > But even though I have a lock on the front door of my house, I have a
> > key for it hidden nearby. It's not bad practise to provide a way to
> > circumvent a system in unusual circumstances.
>
> It is if you have a sign pointing everyone to the key.

Worse, it's a sign that everyone would have as a requirement for their houses.

I agree with the metaphor, not with the conclusion: it's equivalent to having
a workaround for weird conditions, especially for writing debugging code. But
not a standard one: everyone can design their own and invent their own
mechanism to protect from abuse.

For example, for Qt, QObjectPrivate::get() takes a QObject pointer and returns
the QObjectPrivate pointer that is inside, thus allowing any arbitrary code
that can #include <private/qobject_p.h> to get the QObjectPrivate for any
QObject, and thus also static_cast that to a descendant class.

Our defence mechanism is that the qobject_p.h header has the "We mean it"
comment.

// W A R N I N G
// -------------
//
// This file is not part of the Qt API. It exists for the convenience
// of qapplication_*.cpp, qwidget*.cpp and qfiledialog.cpp. This header
// file may change from version to version without notice, or even be removed.
//
// We mean it.

An extra protection I have developed but never pushed is to use the ELF
version to tag everything that includes these headers.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel DCAI Cloud Engineering