The second piece (uniform call syntax) looks convenient, though I don’t see a realistic way to integrate it into modern C++. The first (structural pattern matching) is, for me, more of a dividing line between low- and high-level languages. I tend to avoid it in my C++, just as I avoid inheritance, virtual functions, and exceptions… or `<functional>` header contents.

Still, it’s always fun to stumble on corners of the STL I’d never paid attention to, even if I won’t end up using them. Thought it was worth sharing :)

> With the kitchen sink approach of design I’d not be surprised if these get into the language eventually.

Based on the history of C++, they will, but with extremely bizarre syntax. Instead of a.foo(b), it will be something like a@<foo>::&{b}.

  perform(a -> a.add(1))

  perform(VeryLongAndComplicatedAddingIntegerFacade::add)

> * structural pattern matching

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p26...

I don't find it surprising. My impression is that people like Herb Sutter and Alexander Stepanov actively pushed in that direction in the early days. `<functional>` was, AFAIK, part of the STL before it got incorporated into the C++ standard library.

> * uniform function call syntax that is : a.foo(b) vs foo(a, b) being interchangeable.

Herb Sutter has proposed this: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p30... (twice, even, there was an older version of the paper several years ago that didn't pass).

I'm resolutely opposed to such a thing because, having had to actually wade through C++'s name lookup and overload resolution rules in the past, they're a dense, confusing morass of logic that you can only stand to stare at for a half-hour or so before your brain turns to mush and you need to do something else, and anything that adds to that complexity--especially in "this makes things two things nearly equivalent"--is just a bad idea.

(For an example of C++ overload resolution insanity, consider this:)

    // Given these overloads...
    void f(std::float32_t);
    void f(double);
    // Which one does this line call? Assume float/double are standard IEEE-754 types.
    void f((float)1);

Achieving uniform call syntax is easy, compilers just need to implement a new form of symbol resolution called "Kaiser lookup". It follows 14 easy to understand rules. It first looks up methods, then searches for template definitions in /tmp, then for a matching phase of any Saturn moon at time of compilation, then looks of definitions std::compat, and then in the namespaces of the types of any variables in scope anywhere on the call stack. If none of those work, it tries to interpret the call syntax as a custom float literal, and if even that fails, as a Perl 4 compatible regex. It's really intuitive if you think about it.

Another missing piece is a good syntax. C++ has, as you said, most of the capabilities already, but actually using them will quickly turn the code into symbol vomit.

There are actually a few functional programming in C++ books out there. The language has changed a lot since C++98, when this would be unthinkable. Alexander Granin maintains a curated list of functional programming C++ resources [1].

[1] https://github.com/graninas/cpp_functional_programming

> uniform function call syntax that is : a.foo(b) vs foo(a, b) being interchangeable.

Ive written a lot of c++ in the past but I'm not particularly knowledgeable about fp, so I'm wondering why this is important. Is it syntactic sugar or something more significant?

  data |> foo(bar) |> baz

  return baz(foo.bar(data))

    data |> bar(foo) |> baz

    data |> bar(&foo) |> baz

  (.-> foo bar baz)

> * structural pattern matching

Yes, but that has to come with proper sum types. std::variant doesn’t quite cut it.

I’d also absolutely require a simpler lambda syntax. The current one is terrible for one-liner lambdas.

> The two missing pieces are -

For three decades, many people have said "C++ is nearly usable, except for just one thing..." Many of those people have gotten their way, which is why C++ is now a kitchen sink of mutually inoperable, poorly thought-out features, like someone implemented the entire index from Journal of Programming Language Design.

If you don't believe me, check out the implementation of `flip` at the end of the article. Over a hundred lines of templates, variadic parameters, constexpr, r-value references, parameter forwarding, default and explicit constructors, and other things that, imho, simply should not exist in a modern programming language.

So, instead, I'd say the best thing for C++, and the world, would, at this juncture to stop adding features.

    flip :: (a -> b -> c) -> b -> a -> c
    flip f x y  =  f y x

    def flip(x):
        return lambda *z: x(*reversed(z))

           R3 = GHC.Types.[]_closure+1;
           R2 = 97;
           Sp = Sp - 16;
           call GHC.Show.$fShow(,)_itos'_info(R3,
                                              R2) args: 24, res: 0, upd: 24;

the best feature I love in python is:

  s = someobj()
  ref1 = s.doOne
  ref2 = s.doTwo
  // then later
  ref1(arg1,arg2)
  ref2()

In Java you need to code like a crazy to have similar results. Also

  m = someclas.doThree
  // later  
  o = someclas()
  o2 = someclas()

  for i in [o,o2]:
     m(i)

so many patterns done easy and the right way

THUITFHNGL

Fortunately almost all the functional features in the article, like range folds and negation wrappers, do exist.

I skimmed the post. I have absolutely no idea what std::flip is supposed to do. All the sample code looks awful and undesirable. And that’s coming from someone who writes C++ every day. Yes I read the plot twist at the end, made me lol.

  void f(int, double);

  void main() {
    flip(f)(3.14, 1);
  }

No more of a loaded footgun than trying to do it manually, I don't think.

Geographic points should probably be represented as a labeled structure to prevent confusion and passed into functions as such. Using two separate libraries with mutually incompatible error-prone APIs as described is the real loaded footgun IMO. If you can't find better libraries, write wrappers; if you don't have time to write/maintain wrappers, pray. Anything else is just a bandaid.

Probably no better or worse than the alternative. That aside, the example doesn't understand the standards in question.

The governing standard for geospatial data representation is ISO 19125, which defines (longitude, latitude) order. GeoJSON naturally conforms to ISO 19125 since it is a format for processing data on computers.

ISO 6709 is essentially a print formatting standard and orthogonal to storing geospatial data on computers. That some data file formats happen to be human readable does not make ISO 6709 apply.

If you are processing geospatial data on computers the correct order is always (longitude, latitude).

> someone is bound to accidentally use it {zero, two} times

That risk is inherent to the problem at hand, and has nothing to do with std::flip.

When C++23 is fully supported functional style will be somewhat bearable, but even then a lot is missing. Lambdas are just too verbose to make this fun.

For higher arity there is a combinatorial explosion of all the possible permutations.

But if you want to flip the 2nd and 3rd argument in Haskell it can be done by flip itself:

flip23 foo = (\x -> flip (foo x))

Your python code allocates an array and inverts it every function call.

The C++ code has no overhead and is equivalent to a compile time transformation.

There's a somewhat easier way to implement 2-argument-function flip in C++ than the blog post provides:

  #include <functional>
  constexpr auto flip(const auto& f) {
    return std::bind(f, std::placeholders::_2, std::placeholders::_1);
  }

The best I could get the fully general version is still pretty obtuse though:

  // std doesn't have a template version of placeholders::_1, _2, etc., so we need to
  // define our own. 
  template <int I> struct placeholder{};

  template<>
  template<int I>
  struct std::is_placeholder<placeholder<I>> : std::integral_constant<int, I> {};

  // flip must be an object so that the function type can be deduced without needing
  // to explicitly specify its parameters' types.
  template<typename F>
  struct flip {
    const F f;
    
    // operator() deduces the argument types when the flip object is called, but really
    // all we need to know is the number of arguments. 
    template<typename... Args>
    constexpr auto operator()(Args... args) {
      return bind_reversed(std::make_integer_sequence<int, sizeof...(Args)>{})(args...);
    }
    
    private:
    // a helper function is needed to deduce a sequence of integers so we can bind all
    // the placeholder values.
    template<int... Is>
    constexpr auto bind_reversed(std::integer_sequence<int, Is...>) {
      return std::bind(f, placeholder<sizeof...(Is) - Is>{}...);
    }
  };

> And the name smells sus. I don't think the committee would name it "flip" if it did exist. Too short a name for something too niche.

Yeah, this would be std::reverse_bind() or something.

Funny enough, I've known it exists. I've never really found much of a use case for it. Where I have found it "might" be useful is rare one-off APIs. If I were to write a wrapper for one API to work with an equivalent API, then maybe I might use this. But for one-off things, it's not important enough to use IMO.

On the other hand, I remember reading it and thing it was a bit-flip operation since it's in <functional> instead of <tuple>. So I was quite surprised to find that it's really much more like a tuple operation (which is template magic) than bit flipping (at runtime, or possibly also constexpr)

> `std::flip` finds its roots in functional programming, a domain in which it is extremely prevalent:

This is enough to determine it is written by Chatgpt.

If you're not familiar with Chatgpt, ChatGPT finds its roots in advanced machine learning research, particularly in the field of natural language processing (NLP), where it leverages deep learning models like GPT (Generative Pretrained Transformer) to understand, generate, and interact with human language based on vast amounts of data and context.

That DOES seem easy, but it's because the code you wrote only works for functions of two arguments.

Can you write a Haskell version that works for functions with any number of arguments?