As we (again) talk about UFCS, I do not remember did we had a proposal to
use explicit object parameter (a.k.s. deducing this) for this purpose?
For example:
void foo(this int& self, int other)
{
 // Do something...
}

Of course I am not sure if this approach would break things.

Dragan Grbic


On Mon, Sep 29, 2025 at 5:13 PM Arthur O'Dwyer via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Sun, Sep 28, 2025 at 11:13 AM Bad At The Game via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>> Hi, I tried to take another approach at UFCS, Here
>>
>> https://github.com/ZXShady/proposals/blob/main/alternative_free_function_call_syntax.md
>> It isn't professionally written I tried my best.
>>
>
> FYI, if you were to elevate this into an actual WG21 proposal, it would
> need to have a real person's name on it, not "Shady".
>
> FYI, your Clang patch
> <https://github.com/llvm/llvm-project/compare/main...ZXShady:llvm-project:alternative_free_function_calling_syntax>
> seems to have a lot of extraneous diffs. I bet you ran `clang-format` on
> the entire codebase, or on the files you touched. Don't do that. Instead,
> run `git-clang-format --diff --extensions ',h,cpp' HEAD~4 --` to format
> only the exact diffs that you made, leaving the rest of the file's
> formatting intact.
>
> Consider hyperlinking to CWG 1089
> <https://cplusplus.github.io/CWG/issues/1089.html> instead of the more
> cumbersome CWG 1089
> <https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1089>.
>
> The idea seems identical to the pre-existing (and apparently
> stalled/abandoned) P2011
> <https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2011r1.html>
> proposal of a "pipeline operator" — with two differences:
> (1) You use the existing token `.` instead of P2011's new "pizza operator"
> `|>` (which required lexers to change to accept `|>` as a single token).
> (2) You limit the right-hand-side "operand" to begin lexically with `
> *identifier* ::` in addition to whatever P2011 says.
>
> Your discussion of CWG 1089 focuses on `p->T::f()`, not `p.T::f()`. Are
> you trying to propose that `p -> T::f()` should act the same as your new
> `(*p) . T::f()`, or differently from it? Either way seems bad. IMHO the
> original sin here was trying to reuse `.` as the pipeline operator, instead
> of picking a completely new operator like P2011's `|>`.
>
> It's unclear to me (since you didn't provide wording) whether you intend
> to support both
> int x1 = 1;
> int y1 = x . std::max(2);
> (where lookup finds an overload set of function templates) and also
> int x2 = 1;
> int y2 = x . std::ranges::max(2);
> (where lookup finds a single global variable, which happens to be a
> niebloid). Ctrl+F for "ranges::", "nieb", "cpo" didn't find any discussion
> of what you mean by "only finds free functions."
>
> Come to think of it, it's also unclear what you would do with:
> struct S { int f(int); static float f(S&, int); };
> S s;
> int y3 = s . S::f(2);
> Is this now going to be rewritten into `S::f(s, 2)`, or will you keep the
> old behavior and make it call `s.f(2)`? Does anything change if the name
> `S` in this context refers to a namespace? Godbolt:
> <https://godbolt.org/z/1boz51v59>
> namespace N {
> struct S {
> int f(int) { return 1; }
> static int f(S&, int) { return 2; }
> };
> }
> namespace S {
> int f(N::S&, int) { return 3; }
> }
> int main() {
> N::S s;
> return s.S::f(2); // today this returns 1
> }
> With P2011's pizza operator, the semantics are obvious (at least in this
> case):
> return s |> S::f(2); // today this is illegal; tomorrow it rewrites
> into S::f(s, 2) and therefore returns 3, no ambiguity at all
>
> Basically, you have some minor procedural problems with the proposal, and
> then you have a major fatal flaw due to your trying to reuse `.` (and maybe
> `->`?) as your pipeline operator instead of inventing a new one.
>
> –Arthur
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>