I think this claim has some merit. Perhaps the only thing missing (or perhaps intended to be self-evident) is that ad-hoc polymorphism is also useful and pragma

I think this claim has some merit. Perhaps the only thing missing (or perhaps intended to be self-evident) is that ad-hoc polymorphism is also useful and pragmatically, this situation doesn't come up too often. In particular, encapsulation reduces the frequency that such errors can be introduced. In the article's example, the `Setting` struct should (idiomatically) have private elements and use a method in the struct's impl block to expose the (optional) length of the field. And, to support the author's point, you wouldn't use ad-hoc polymorphism for this either. The author's concern should be considered when introducing ad-hoc polymorphism, especially when the type bounds are "loose" or commonly defined by many types.