Что ещё надо, я хз

тогда это нерешаемая задача

Ща попробую

У вас бывает чувство, что вас накормили гавном? Если нет то попробуйте читать все новые RFC для пыхи. Вот 1 пример:
https://github.com/Girgias/intersection-types

Я даже не знаю как это откоментировать и стоит ли. Насколько крутые были все изменения начиная с 5.4 до 7.4 настолько же убогой мерзостью язык пытаются сделать теперь. Все обновления можно поеделить на два вида:
1. Бесполезный синтаксический сахар, который ухудшает чтение.
2. Реально вредные изменения, которые провоцируют разработчика на уебищные архитектурные решения.

Здесь у нас явно второй случай. Причем в доке к RFC мы видим милые примеры вида:

/** @var Traversable&Countable */

Которые в реальных проектах превратятся в:

/** @var Traversable&Countable&Convertable&HashMapable&Array&Moveble&Yadolboeble&SomethigElseble&ITD */

С какой целью и зачем это делается мне непонятно, жаль только чем уебищнее RFC с тем большей легкостью оно проходит одобрение :(

А вам нравится куда движется язык?

/** @var Traversable&Countable */

пора делать форк

/** @var Traversable&Countable */

это же не union, это intersection

/** @var Traversable&Countable */

можно конечно заводить расширяющие интерфейсы, но когда ты будешь на каждую комбинацию встроенных или вендоровских заводить свой - получишь некислую кашу

/** @var Traversable&Countable */

ну т.е в твоем адовом примере это решается заведением одного интерфейса, который экстендит все нужные - но это сработает только, если у тебя есть возможность имплементить этот интерфейс на объекте

/** @var Traversable&Countable */

в целом да, подобная каша вообще признак плохого построения класса, но имхо кейсы где ты интерсектишь 2 интерфейса имеют право на жизнь

/** @var Traversable&Countable */

просто подтягиваются до уровня тайпскрипта. где пыха и где тайпскрипт

вполне, нередко делают класс, реализующий несколько интерфейсов. как его передать? делать новый интерфейс? классом? теперь можно не делать лишних костыль-сущностей, а просто передать тип "как есть"

при этом не будет соблазна дернуть то, что интерфейсом не предусмотрено

не понял?) тут обратный кейс, использование а не написание классов)
т.е почти любой пример можно просто разбить на 2 разных класса, каждому из которых нужен свой интерфейс и они выполняют конкретное действие. Исключением является всратая бизнес-логика и кейсы где разбивка действия по двум классам наоборот усложнит восприятие и поддержку

но лучше бы typedef конструкции завели - было бы удобнее, чем все эти всратые портянки городить

Короче в винде перекодировал и отправил обратно))

ну т.е. придется иметь 2 поля, в которых будет один и тот же объект передан

/** @var Traversable&Countable */

если ты хочешь чтобы входной объект твоего класса реализовывал 2 интерфейса - то либо твой класс планирует делать 2 вещи, когда может делать одну, либо interface segregation понят не так и кто-то разбил интерфейсы максимально всрато, либо ты почему-то не можешь явно задать контракт класса одним интерфейсом

в целом да, инициатива противоречит слегонца солиду.

с другой стороны, в этом контексте - union types еще большая дичь. если в intersection еще смысл понятен, то union... это как? мне надо это, или это, или это? тут уж явно нарушен принцип единственности)

S этот хитрый, собака) например, пишут

A module should be responsible to one, and only one, actor.
Старая формулировка: A module should have one, and only one, reason to change.

т.е. уже всё не так однозначно)