I have zero problems using type inference, tuples, etc in my code. Other developers I deal with and who do use C++ have no problems using those "novel" concepts either. So I am completely at loss about what type of culture you are talking about here. It looks like grasping at a straw type of argument to me.

I'm talking about all libraries and books written since it's development up until the early 10s; and of all those teams, libraries, and code which are legacy.

Haskell has never had a decades-long history of 'compiler-oriented programming', ie., excessive declarations, and so on.

The idea that C++ has a haskellish culture is patently absurd, even if the vanguard regard itself as presenting tending toward that direction.

I am in no way implying that "C++ has a haskellish culture". Neither I would consider it of any advantage. All I said is that modern C++ programmers have no problems using the concepts. There is plenty of those that are used in gobbles of libraries as well. Sure old libraries do not have it but so what?

So, OCaml or something?

Or has Haskell added structural typing?

Haskell is structurally typed...

Hmm, what do you mean? Haskell is generally considered nominally typed (or rather types introduced by its newtype and data declarations are ...). "Structural typing" typically refers to things like polymorphic row types and polymorphic variants.

Sure, my mistake. I meant something looser.

Only that the types can be analysed structurally (ie., pattern matched).

In C++, etc. there's a "radical nominalism" in which the type was very opaque, ie., encapsualated.

It is complicated. Templates do allow some form of structural typing and the new-in-C++17 structured bindings do allow for decomposing and inspecting types (although this being C++ it is kind of awkward). Structured bindings are expected to evolve into full pattern matching in the future.