<!DOCTYPE HTML>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
	<title>Do not remove nor postpone access_context::unchecked</title>

	<style>
	p {text-align:justify}
	li {text-align:justify}
	blockquote.note
	{
		background-color:#E0E0E0;
		padding-left: 15px;
		padding-right: 15px;
		padding-top: 1px;
		padding-bottom: 1px;
	}
	ins {color:#00A000}
	del {color:#A00000}
	</style>
</head>
<body>

<address>
Document number: P3614R0
<br/>
Audience: EWG
<br/>
<br/>
<a href="mailto:ville.voutilainen@gmail.com">Ville Voutilainen</a><br/>

2025-02-06<br/>
</address>
<hr/>
<h1>Do not remove nor postpone access_context::unchecked</h1>

<h2>Abstract</h2>

<p>In <a href="https://open-std.org/JTC1/SC22/WG21/docs/papers/2025/p3547r0.html">P3547</a>, Dan Katz and I propose adding an access_context, and that
  has three different forms:
</p>
<ul>
  <li>access_context::current(), the current context's access</li>
  <li>access_context::unprivileged(), the equivalent of public access</li>
  <li>access_context::unchecked(), which bypasses access controls</li>
</ul>
<p>
  SG7 discussed the paper, and had this poll result:
  <pre><blockquote>P3547R0: SG7 wants reflection to provide user-accessible access_context::unchecked() in C++26.
SF 	F 	N 	A 	SA
4 	3 	3 	1 	3

Result: not consensus
  </blockquote></pre>
</p>
<p>
  We should keep access_context::unchecked. It's necessary, it's necessary
  for generic algorithms, and it's part of a set of fundamental use cases
  of reflection.</p>

<h2>Elaboration</h2>

<p>Reflection (and injection) isn't just about auto-generating boiler-plate
  that you can already write manually. A significant part of it aims
  to make C++ a <em>programmable programming language</em>. And that aim
  means making C++ a programming language programmable in itself.
</p>
<p>
  So what does that mean? Well, for the parts relevant for this discussion,
  it means that the language should expose its internal magic, the tricks
  that compilers know how to do, and allow reflection+injection metaprograms
  to use and reuse that magic.</p>
<p>It means that we absolutely should be able to write new traits
  with just reflection facilities. We shouldn't need to crack open
  a compiler's codebase and extend that to do so. We should be able
  to write new language facilities in terms of reflection, and if those
  facilities require probing members of a class, regardless of access,
  and looking at whether any of them have a particular property, we
  should be able to do so.</p>

<p>Because the point of a programmable programming language is that you
  can extend it without having to hack on a compiler.</p>

<p>Sometimes a new facility like that, written with reflection, needs
  to access otherwise inaccessible members, and needs to do so generically,
  without asking for a concrete type to cooperate. And it's infeasible
  to expect all types compatible with such a facility to somehow opt in
  to something, not all facilities are like that.</p>

<p>access_context::unchecked makes that possible. It also makes it visible,
  and easy to find, and easy to control and check that when you do things
  like that, they're subject to necessary scrutiny by reviewers, not hidden
  behind hacks. But nevertheless they are possible, like they need to
  be if we want to make the language more programmable and want to make
  it less necessary to change a compiler to extend the language. Like we
  have already agreed to do for reflection and injection, in many ways.</p>
</body>
</html>
