Да вообще & в типах выглядит как ошибка проектирования, как

по мне.
Давай подумаем без интерфейсов. Вот будет int&string – что это за зверь? "или" – еще ок, но "и" никуда не годится.

не надо думать без интерфейсов )

Для такого создаются композитные интерфейсы 🙂

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

+

В дату нашу загляни

interface Decoder { public function decode(string $token): array; } interface Encoder { public function encode(array $payload): string; } final class JwtGuard implements Decoder, Encoder { ... } Где-то нужен Encoder, я внедряю Encoder. Где-то нужен Decoder, я внедряю Decoder. ISP соблюден. А где-то мне нужен и Encoder, и Decoder. У меня есть 2 варианта 1. Создать композитный интерфейс. Как назвать? Зачем он мне нужен? 2. Использовать напрямую JwtGuard. Вместо этого я делаю: public function registerUser(Encoder&Decoder $guard) {}

И что будет внутри метода registerUser?

Это важно?

Ты же можешь в пример добавить Encoder&Serializer. А то, что внутри будет мясо, об этом никто не поспорит. Такие примеры и возникают, что без конкретных примеров, которую должна решить эта доработка, всё выглядит "ого, было бы прикольно". А в коде выходит каша. Как ты решишь ситуацию, когда у двух интерфейсов есть метод с одним и тем же названием, но сигнатура разная?

Кажется, ты не понял, зачем нужно пересечение. То пример со string&int привел, то теперь это. Приводить намеренно не рабочие примеры – это такая стратегия в споре?

И да, вот тебе и название нового интерфейса - Guard. Почему-то вопроса нейминга параметра функции у тебя не возникло :))