There has been some discussion on the list regarding performing access
checks at the time of splicing, and I would like to offer my views on
this issue.


Access controls in reflection were specifically designed so that unsafe
reflections cannot be formed (and therefore cannot be spliced) unless an
unsafe access context is used (it is given the scary name of "unchecked"
for a reason), or the class that has access to this member has given an
explicit permission to access that member by providing a permission
token (the reflection itself).

This affects both non-static members as well as static members, and
whatever "program metadata" is supposed to mean. This is by design and
must not be changed, because access controls are an explicit contract
that differentiates between the stuff you can rely on and the stuff you
can change.

The fact that the analysis of the so-called "program metadata" is
performed at compile-time does not mean that the part of the program
that is doing the analysis is safe to assume that the private data has
any meaning. Because of that, not doing the access checks there will
lead to analysis logic being misled by the program metadata that is not
supposed to be accessed in the first place.

By obtaining the reflection with a privileged or unchecked access
context, we are explicitly given permission to access this data. This
should be the place for audits and attention, not every consumption.

Now, if we perform the access checks at the appropriate time (when
producing the reflection), the reflections that do end up being consumed
(either by extract, or splicing, or whatever else) are already safe -
because the reflection itself is a permission token allowing interaction
(similar to a pointer-to-member).

If you really want to be paranoid about accesses, you can static_assert
that the reflected value is still accessible in the context of the
splice, by using std::meta::is_accessible.


Please, leave the current semantics unchanged.