On Wed, Dec 9, 2020 at 9:33 PM David Bakin via Std-Discussion
<std-discussion_at_[hidden]> wrote:
>
> I just learned about this exception to the access rules (there are several posts on SO about it, plus there's an originating GotW article about it quite awhile ago).
>
> So you can use this to legally access protected and private members of a class, if you're willing to suffer Mr Sutter's disparagement of your gentlemanliness.
>
> My question is: why? What is - or are - the motivating use case(s) for this loophole?

It's the outgrowth of the following:

1) Member function definitions can be written inside or outside of a
class with no linguistic distinction between them
2) Explicit specializations are function definitions.

If you want both of these to be true, then this is the result you get:
someone can specialize member functions outside of the class
definition. Since they're members, they get access per any other
member of the class.

The "motivating use case" is that the language would be rather silly
otherwise. The only ways to "fix" this "loophole" would be to stick a
giant hack in the middle of one of the above. You could make
out-of-class member functions be unable to access privates, but that's
a terrible idea for any number of reasons (even ignoring the giant
compatibility break it would cause). You could make explicit
specializations outside of a class definition a special kind of thing
and therefore subject to its own rules, but then the writer of that
class would *have* to put all specializations inside of the class
definition.

With the existence of modules, it would be nice to allow a module file
to be able to declare that a template cannot be specialized by any
code outside of that module. But in a world where modules don't exist,
there is no way to distinguish out-of-class definitions written by the
author of the class from out-of-class definitions written by "other
people".