А в каком состоянии сейчас обсуждения по лупхолам? На них уже можно закладываться? Я заметил, что на их основе, потенциально можно собирать во время компиляции статистику об инстанцированиях и, возможно, даже автоматически провести какие-то оптимизации типов данных и работы с ними, которые раньше требовали больше ручного контроля или бойлерплейта.
Так что, стоит лупхолы рассматривать как потенциально полезный механизм или стоит подождать какой-то определённости?
The current state is that the C++ core working group has agreed that they intend to make the technique ill-formed, but the mechanism for doing so has not yet been agreed upon.
Recently I suggested this as a solution to a collection of issues including 2118, and it was received well:
"""
For a function that is inline or has a deduced return type, the name lookup performed for each reference to the function that requires a definition to exist shall find a declaration of the function that is introduced in the same scope as the definition. For this purpose:
-- a function declaration with a qualfiied name is considered to be introduced in the scope of the declaration named by its nested-name-specifier,
-- a non-defining friend function declaration with an unqualified name is considered to be introduced in the scope in which the function is introduced or redeclared,
-- a function declaration at block scope is considered to be introduced in the innermost enclosing namespace scope, and
-- any other function declaration is considered to be introduced in the scope in which it appears. [Note: Friend function definitions are introduced in the enclosing class scope.]
"""
The specific case of this for CWG2118 would be: for a function F defined in a friend declaration in some class C, the class C shall be an associated class for all potentially-evaluated calls to F.
It's not yet clear whether this is too restrictive (there are cases where this forces a friend function to be defined outside of a class where it is currently defined inside the class, so it would be a breaking change for code that might be considered reasonable), and we've certainly not made any decision. But every time the core working group has considered the issue, they have concluded that they want to make such code ill-formed somehow.
