On Mon, Sep 19, 2022 at 7:38 PM William Linkmeyer via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> If UFCS has no clear path to get into the standard (which, last I checked, was still a topic with good discussion and positive momentum),

Um, how exactly did you "check" this? If you checked Reddit, forums,
Twitter, and the like, I'm sure there's lots of discussion and
"positive momentum".

But you'll find far less if you check things that actually matter for
people who attend committee meetings and vote on proposals that affect
millions of C++ programmers. From what I can tell, since C++17 landed,
there have been very few proposals in the direction of UFCS. The
closest thing I could find to recent papers talking about UFCS was
P2011, about creating a pipeline operator overload. And the pipeline
overload is presented as a better tool for the job.

And even that paper has lain fallow for 2 years.

So where is the "positive momentum" in terms of actually causing it to
get standardized?

> then I’ll write a language, transliterating to C++, which is capable of supporting it.

Well, good luck with that. I mean, I don't know why anybody who is
willing to abandon their already existing C++ codebase would pick your
language rather than any of the better developed alternatives. But one
more for the pile, I suppose.

> It’s an important feature.

What is an important feature? I mean that: specifically *what* is the
feature you're wanting here? Because nobody actually wants UFCS.

What people want is a solution to some particular problem, and UFCS is
a hypothetical solution to a *lot* of problems. Most of the time, when
people advocate for UFCS, what they're advocating for is a solution to
their specific problem.

Notably a solution that requires as little action from themselves as
possible, putting the burden of dealing with the consequences of UFCS
on other people.

> The lack of pattern matching and the slow-crawl to Herb’s “cppfront” syntax almost encouraged me to write such a language front-end previously.