The C++ usage (T x{{}}) is problematic because its interpretation is so obscure as to flirt with ambiguity and lead to program-breaking changes in compilers as their semantic analyzers improved. The Haskell line you cite isn't ambiguous at all.

Ambiguity, yes it has none.

About obscurity, how many GHC extensions were required to make it accept this code? (Is GADT enough?) And by the way, this is in the interface, while the C++ example is in the implementation.

Besides, that's Haskell code that happens in practice. This is one I've just looked at, if I did some research I would certainly come up with more egregious code (maybe even mine). This one probably isn't even problematic (it's hard to say from the interface), but in general, mixing those extensions does lead to some very interesting problems from time to time.

Haskell has the same excessive complexity problem that C++ suffers. I do think this is the right thing to do right now. But I can't imagine it not looking as dated in 4 decades as C++ is now.

Ah, but most of the complexity in that line is an artifact of how Haddock (egregiously badly) generates documentation. The line in the source code is

    instance (Patchy p, ApplyState p ~ Tree) => Patchy (PatchInfoAnd rt p)

I don't personally like typeclassitis, but this is actually easy to interpret:

"If 'p' is a patch-like thing, and its ApplyState is a Tree, then 'PatchInfoAnd rt p' is a patch-like thing"