Why does c++ have this rule:Explicit instantiation definitions ignore member access specifiers: parameter types and return types may be private

According to this rule, C++ can directly destroy encapsulation under safe syntax

c++11

#include <iostream>

class A {
 public:
  A() = default;
 private:
  int data_ = 0;
};

template < int A::*Member >
class Access {
 public:
   friend  int GetPrivateData(A& obj) {
     return obj.*Member;
  }
};

template  class Access<&A::data_>; // explicit instantiation

int GetPrivateData(A& );


int main() {
  A obj;
  GetPrivateData(obj);

  return 0;
}

//https://www.zhihu.com/question/521898260/answer/2876618819

c++17

class A {
 public:
  A(int num) : data_(num) {};
 private:
  int data_ = 0;
};

template <typename PtrType>
class Access {
 public:
 inline static PtrType ptr;
};

template <auto T>
struct PtrTaker {
    struct Transferer {
        Transferer() {
            Access<decltype(T)>::ptr = T;
        }
    };
    inline static Transferer tr;
};

template class PtrTaker<&A::data_>; // explicit instantiation

int main() {
  A a{10};

  int b = a.*Access<int A::*>::ptr;
  
  return 0;
}

//https://www.zhihu.com/question/521898260/answer/2876618819

The two implementations have slightly different principles. The former can be regarded as exploiting linking vulnerabilities, but the latter is indeed a completely standard implementation.

And this syntax cannot be checked by a simple keyword search, because there will be a lot of normal explicit instantiation to confuse.

The behavior you are referring to is specified in [temp.spec.general]/6

This rule has been there since C++98, so since the first standardization of C++. It is not somehow new with C++17.

The rule is also necessary. Suppose you wanted to use Access<&A::data_> inside A, where A::data_ is accessible, but you then don't want Access<&A::data_> to be implicitly instantiated, only explicitly instantiated in a single translation unit. Because the explicit instantiation declaration cannot appear inside A's scope, there can't possibly be any check on accessibility. It would make such an explicit instantiation completely impossible.

The same applies to explicit and partial specializations as well.

That you can use additional techniques such as friend injection to then access the private member is not a problem, since these are not things that can happen accidentally. If the user is determined to access a private member, then there isn't anything stopping them anyway. (They could for example simply add their own class/function as a friend in the class definition, which may or may not be an ODR violation in itself, but will have no negative consequences as such in practice.)

The purpose of access control is only to make it so that the user won't accidentally use a member that they shouldn't use directly and merely instantiating with a private member as argument doesn't allow accessing the private member. That requires additional targeted work. And if a user does all that work to get to the private member, then the user is intentionally breaking the intended use of the class and it will be on them if the result is a broken program.