Date: Thu, 8 May 2025 11:05:12 -0700
Have you ever tried just asking one of the current LLM implementations?
After starting a conversation with:
> Can you tell me a bit about the asynchronous execution model design in
recent C++ papers hosted at
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/
(ie something I knew about and to give it the URL as context) I asked your
question. Claude Sonnet 3.7 came back with:
> "Has anyone ever suggested that a class should be able to attain
multiple friends through the use of just one friend statement combined with
a parameter pack? For example: template<class... Ts> class MyClass {
friends... Ts; };"
Yes, this concept has been proposed in various forms. What you're
> describing is essentially a "variadic friends" feature that would allow
> declaring multiple friend classes or functions through a template parameter
> pack.
> While the exact syntax you proposed (friends... Ts;) isn't part of the
> C++ standard, there have been discussions and papers about similar
> functionality. The general idea would be something like:
> template<class... Ts>
> class MyClass {
> template<class... Ts> friend class; // Or some similar syntax
> // Alternatively: friend Ts...;
> };
> This kind of feature would be useful in template metaprogramming scenarios
> where you want to grant friendship to a set of related types generated from
> a template.
> There are a few challenges with such a proposal:
>
> 1. Syntax design that aligns with C++'s existing grammar
>
>
> 1. Semantic questions about how the friendship would propagate across
> template instantiations
>
>
> 1. Questions about whether friendship should be granted to all
> instantiations of a template or only specific ones
>
> The C++ committee generally approaches friendship features carefully since
> they impact encapsulation. I don't believe this specific feature has been
> standardized yet, though similar ideas have been discussed in committee
> papers.
> Alternative approaches currently used include:
>
> - Using a base class with protected members
>
>
> - Using explicit friend declarations for each needed type
>
>
> - Using a proxy pattern to grant controlled access
>
> Would you like more information about current workarounds for this use
> case or the status of any similar proposals?
Is it accurate? I don't know. Usual caveats. Just a demo to question
whether a custom website and customization of the model would even be
necessary.
After starting a conversation with:
> Can you tell me a bit about the asynchronous execution model design in
recent C++ papers hosted at
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/
(ie something I knew about and to give it the URL as context) I asked your
question. Claude Sonnet 3.7 came back with:
> "Has anyone ever suggested that a class should be able to attain
multiple friends through the use of just one friend statement combined with
a parameter pack? For example: template<class... Ts> class MyClass {
friends... Ts; };"
Yes, this concept has been proposed in various forms. What you're
> describing is essentially a "variadic friends" feature that would allow
> declaring multiple friend classes or functions through a template parameter
> pack.
> While the exact syntax you proposed (friends... Ts;) isn't part of the
> C++ standard, there have been discussions and papers about similar
> functionality. The general idea would be something like:
> template<class... Ts>
> class MyClass {
> template<class... Ts> friend class; // Or some similar syntax
> // Alternatively: friend Ts...;
> };
> This kind of feature would be useful in template metaprogramming scenarios
> where you want to grant friendship to a set of related types generated from
> a template.
> There are a few challenges with such a proposal:
>
> 1. Syntax design that aligns with C++'s existing grammar
>
>
> 1. Semantic questions about how the friendship would propagate across
> template instantiations
>
>
> 1. Questions about whether friendship should be granted to all
> instantiations of a template or only specific ones
>
> The C++ committee generally approaches friendship features carefully since
> they impact encapsulation. I don't believe this specific feature has been
> standardized yet, though similar ideas have been discussed in committee
> papers.
> Alternative approaches currently used include:
>
> - Using a base class with protected members
>
>
> - Using explicit friend declarations for each needed type
>
>
> - Using a proxy pattern to grant controlled access
>
> Would you like more information about current workarounds for this use
> case or the status of any similar proposals?
Is it accurate? I don't know. Usual caveats. Just a demo to question
whether a custom website and customization of the model would even be
necessary.
Received on 2025-05-08 18:05:26