构建器模式是否比命名的可选参数提供的功能更多？

问：

Head First Design Patterns 在附录中仅简要描述了构建器模式，没有像其他模式那样专门讨论它。

设计模式：可重用面向对象软件的元素将其视为其他设计模式。

重构 Guru 还将构建器模式视为“真实”模式，而不是将其降级为附录。

无论如何，在我看来，第一个和第三个来源都非常关注模式如何有效地构建一个具有客户想要的“成分”的对象。

换句话说，一个糟糕的解决方案是拥有这样的构造函数

Ctor::Ctor(Param1* param1, Param2* param2, Param3* param3 /*, and many more */);

不需要设置前两个参数的客户端需要这样调用

auto obj = Ctor(null, null, some_param3 /*, null, null */);

而构建器模式将允许人们像这样构造一个对象：

auto obj = Builder().setParam3(some_param3).build();

但是，如果解决的所有构建器模式都是上述问题，那么我觉得命名参数将提供相同的解决方案（而且我不是唯一一个对此感到疑惑的人）。反过来，我会将“构建器模式”称为“命名参数模式”，它指导您用缺乏它的语言实现此功能。

事实上，网络上有一些消息来源声称其他语言不需要这种模式（或者，如果你愿意，这种模式在它们中不太明显）：

1. 这里有一个令人信服的例子，说明 Clojure 的解构能力如何满足你只将你想要的参数传递给构造函数所需的一切;
2. Facebook的一位研究工程师（至少在他写这篇文章的时候）声称，Haskell的类型类和智能构造函数是你所需要的，没有构建器模式，尽管他没有深入探讨这个话题。

因此，鉴于上述第 1 点，我的问题是构建器模式是否真的提供了更多像命名参数这样的语言功能。

（我把第 2 点排除在外，因为我不确定我是否理解了它。