You can define that befriended function template out of line, but it's
probably not what you want.

template <class T>
class profile_integer {
public:
    explicit profile_integer(T v) : value(v) {}
private:
    T value;
    template <class V>
    friend profile_integer<T> operator*(const V&, const
profile_integer<T>&);
};

template <class V>
profile_integer<int> operator*(const V &value, const profile_integer<int>&
pi)
{
    return profile_integer<int>{value * pi.value};
}
template <class V>
profile_integer<unsigned> operator*(const V &value, const
profile_integer<unsigned> &pi)
{
    return profile_integer<unsigned>{value * pi.value};
}

Each specialization of profile_integer has declared a different function
template not related to the others. Therefore it's not possible to define
all of them with a single definition outside the class. In the existing
example in [temp.friend] paragraph 1, the non-template functions next_time
and process have the same issue: each non-template function can be defined
outside the class, but it's not possible to define them in a general way
for all template arguments outside the class. I agree a little more
explanation about them would be helpful. Would that also satisfy your
original concern?

For the practical issue, you can instead befriend a function template which
is in fact general enough to be defined in one place:

template <class T>
class profile_integer {
    // ...
    template <class V, class U>
    friend profile_integer<U> operator*(const V&, const
profile_integer<U>&);
};
template <class V, class T>
profile_integer<U> operator*(const V &value, const profile_integer<T> &pi)
{ /* ... */ }

It's technically a wider friendship and slightly less encapsulated, since
now each operator* specialization has access to all profile_integer
specializations, not just the matching specialization that's in its
parameter and return types. Somebody could define an explicit
specialization of that operator* and gain access to private members, but as
with many C++ things, we're more protecting against accidents than against
malice. In practice, it's probably not a concern. It's also not possible to
declare that general template then have profile_integer<T> befriend the
specializations for all V but only the specific T, since that would be
declaring a function partial specialization, which isn't allowed even as a
friend.

-- Andrew Schepler


On Wed, Mar 12, 2025 at 9:50 AM Michael Conlen via Std-Discussion <
std-discussion_at_[hidden]> wrote:

> Hi,
>
> I'd like to suggest an edit to [temp.friend] to make the standard more
> clear in a use case I ran into recently. I'm writing to get feedback. The
> use case is as follows; Suppose we have a template class
>
> <template class T>
> profile_integer;
>
> This might be a arithmetic type for which we want to overload operators
> for common types; and so in the definition we wish to have
>
> <template class V>
> friend profile_integer<T> operator*(const V& lhs, const
> profile_integer<T>& rhs);
>
> and we wish to define this out of line. This (and correct me here) is
> impossible. When we instantiate profile_integer<T> for some concrete type T
> we create a friend declaration for operator*<V> but any out of line
> definition would be for operator*<T, V> and these are two different
> functions. In practice this compiles but fails to link for lack of
> operator*<V>.
>
> I think adding to the example in [temp.friend] (1) Example 1 that makes it
> clear that this must be an inline definition and a note in the text below
> would make sense.
>
> While all the elements to explain the above behavior exist in the
> standard, to a casual reader of the standard it may not be abundantly clear
> and a casual reading of the one example of a template friend of a template
> class may suggest that an out of line definition is possible (it's possible
> if the function signature doesn't depend on the class template type.)
>
> If my understanding is correct and this makes sense I believe it would
> fall under an editorial issue and a PR in git would be appropriate, is that
> correct?
>
> Of course I would appreciate it if the standard could support such an out
> of line definition of such a function but I suspect that is non-trivial.
> Please correct me here if I'm wrong.
>
> --
> Mike
>
> --
> Std-Discussion mailing list
> Std-Discussion_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
>