Name
	n3622, alx-0031r2 - Allow calling static inline within extern inline

Category
	Lift useless constraints

Author
	Alejandro Colomar <alx@kernel.org>

	Cc: Christopher Bazley <chris.bazley.wg14@gmail.com>
	Cc: Jₑₙₛ Gustedt <jens.gustedt@inria.fr>
	Cc: Martin Uecker <ma.uecker@gmail.com>

History
	<https://www.alejandro-colomar.es/src/alx/alx/wg14/alx-0031.git/>

	r0 (2025-06-26):
	-  Initial draft.

	r1 (2025-06-26):
	-  Propose alternative wordings, which remove more and more of
	   this constraint, and are less ambiguous.

	r2 (2025-06-26; n3622):
	-  Drop wordings A and B.  There seems to be consensus that we
	   want C.

Principles
	-  Keep the spirit of C:
	   -  Trust the programmer.
	   -  Don't prevent the programmer from doing what needs to be
	      done.

Rationale
	The issue this constraint seems to be protecting from seems to
	be the case where a program uses a static variable defined
	within a static inline function.  So this:

		static inline int si(void)
		{
			static int x = 0;
			return x++;
		}

		inline int ei(void)
		{
			return si();
		}

	This would result in using a different version of 'x' depending
	on whether the function is actually inlined or not.

	However, that issue isn't significantly worse than using the
	same static inline function from a regular function: each TU
	will use a different version of 'x', which doesn't make much
	sense usually.  Let's trust programmers to not be stupid.  If
	anyone does that kind of thing, they most likely know what
	they're doing.  And if not, it should be easy for QoI compilers
	to issue a diagnostic like "hey, you're using a static inline
	function that has a static object in it, from within an extern
	inline function!".  All being inline, the compiler can see all
	the definitions, and is able to issue appropriate diagnostics
	for the extremely rare case where this might happen
	accidentally.

	On the other hand, some libraries define static inline functions
	rather extensively, and other libraries prefer using extern
	inline functions extensively.  And this is a problem, because
	currently they're completely incompatible, and there's no reason
	why the latter shouldn't be allowed to call the former.

See also
	<https://bugs.ruby-lang.org/issues/18893>

Proposed wording
	Based on N3550.

	6.7.5  Function specifiers
		@@ Constraints, p3
		-An inline definition of
		-a function with external linkage
		-shall not contain,
		-anywhere in the tokens making up the function definition,
		-a definition of a modifiable object
		-with static or thread storage duration,
		-and shall not contain,
		-anywhere in the tokens making up the function definition,
		-a reference to an identifier with internal linkage.