类型 - 具有方法参数的“多重类型”（联合类型）的语言？

为简单起见，我将使用 PHP 作为示例语言。让我马上解释这一点。在现代语言中，尤其是解释语言中，传统上存在非严格类型：

function join($a){
   return is_array($a) ? implode('', $a) : $a;
}

并且有严格的打字：

function join(array $a) : string{
  return implode('', $a);
}

例如，还有 C++ 中的模板类型：

template <class T, class R>
R* join(T * array, int count)
{
    R *output = new R(count);
    for (int i = 0; i < count; i++)
      output += array[i] ;
    return output;
}

C++中也有类型重载，但不是很灵活，也很繁琐，像模板类型一样，后者也没有可读性。

但是缺少多重类型（正如我发现的那样-这称为联合类型）-我想要以下内容：

function join(array|Iterator|ICollectable $input) : string|null{
    /*какой-то код обработки*/
}

问题是——是否有任何语言支持类似的类型限制语法，如果有，是哪些？如果不是，这个概念不好的原因是什么？

为什么会出现对此缺乏内置支持的问题 - 具有变体类型的语言的程序员通常在方法注释中写这样的东西：

/**
   * Some function describe
   * 
   * @param array|ISomeList $list ...
   * @return false|string ...
   */

但在 f-ii 声明中，他们被迫不对类型进行显式引用（依赖于注释），从而留下变体类型：

public function someFunction($list) {... return $some;};

这种情况经常发生在不能为了强类型而忽视代码可读性的严肃框架中。

因此，在没有明确指定所需类型的情况下检查代码时：可读性会降低。注释并不能 100% 保证类型限制：程序员和 IDE 一样，无法确切知道输入参数中可以输入什么。当程序运行时——如果输入参数突然出现错误：没有错误/警告发生，这使捕获错误变得复杂，降低了稳定性。

相反，当只使用严格类型时，整个系统变得更加复杂，无可替代：类的数量呈几何级数增长。更糟糕的是，因为类型的非严格性适用于简单的架构决策和可读代码，并且在脚本语言的情况下，它不能被忽视。

UPD：
是的，当然，这样的功能并不完全符合 OOP 的原则。但这将是修改这些原则的理由——因为。他们非常温和地没有考虑到“班级数量的几何增长”。此外，联合类型与鸭子类型结合使用——我不会称之为减号，但这是一个值得争论的大领域。

UPD2：
如果出现多类型有效性的问题：PHP 的一个更生动的例子是声明一个重要的、经常使用的函数，用于从数据库表中选择对象（db-table-mapper）Zend 框架（1.9）类 Zend_Db_Table_Abstract .

/**
 * Fetches all rows.
 *
 * Honors the Zend_Db_Adapter fetch mode.
 *
 * @param string|array|Zend_Db_Table_Select $where  OPTIONAL An SQL WHERE clause or Zend_Db_Table_Select object.
 * @param string|array                      $order  OPTIONAL An SQL ORDER clause.
 * @param int                               $count  OPTIONAL An SQL LIMIT count.
 * @param int                               $offset OPTIONAL An SQL LIMIT offset.
 * @return Zend_Db_Table_Rowset_Abstract The row results per the Zend_Db_Adapter fetch mode.
 */
public function fetchAll($where = null, $order = null, $count = null, $offset = null)
{
    if (!($where instanceof Zend_Db_Table_Select)) {
        $select = $this->select();

        if ($where !== null) {
            $this->_where($select, $where);
        }

        if ($order !== null) {
            $this->_order($select, $order);
        }

        if ($count !== null || $offset !== null) {
            $select->limit($count, $offset);
        }

    } else {
        $select = $where;
    }

    $rows = $this->_fetch($select);

    $data  = array(
        'table'    => $this,
        'data'     => $rows,
        'readOnly' => $select->isReadOnly(),
        'rowClass' => $this->getRowClass(),
        'stored'   => true
    );

    $rowsetClass = $this->getRowsetClass();
    if (!class_exists($rowsetClass)) {
        Zend_Loader::loadClass($rowsetClass);
    }
    return new $rowsetClass($data);
}

根据设计，第一个参数可以是几种类型之一。这是必要的，以便该方法的潜在用户（程序员）很容易将映射器融入他们的头脑。毕竟，他可以通过不同的方式从代码中调用此方法，但方法保持不变：

$table->fetchAll('user_id in (1,2,5)');
$table->fetchAll(['user_id < 100', 'gender = "male"']);
$table->fetchAll( $table->select()->where('user_id IN (?)', $userIdsArray) );

一种方法很容易记住，很适合头脑。虽然 fetchAll 方法的程序员不想将一个任务的逻辑（从数据库中选择对象）分散到他自己内部的多个重载方法中，但他希望所有内容都在一个地方，以便打开的代码立即了解什么是有效的，并且在什么顺序。至少这对应于SRP - 该方法有一个职责：从数据库中选择对象。

即提供一整套语言来与数据库表进行通信。它更像是对程序员的一种服务，而不仅仅是一种方法。框架中的此类方法：每秒一次，因为框架首先应该方便程序员。一个程序员不应该钻研“几千个类”——为了使用特性——这是解决代码可读性问题的一个生动例子，其中联合类型会派上用场。

UPD3 :
事实证明，正如评论中所建议的那样，PHP 开发人员也曾考虑在 2015 年引入这个概念，但他们在投票中否决了。