Почему «застежка-молния» игнорирует свисающий хвост коллекции?

C # , Scala, Haskell, Lisp и Python ведут себя одинаково zip: если одна коллекция длиннее, хвост молча игнорируется.

Это может быть и исключение, но я не слышал ни о каком языке, использующем этот подход.

Это озадачивает меня. Кто-нибудь знает причину, почему так zipзадумано? Я предполагаю, что для новых языков это сделано, потому что другие языки делают это таким образом. Но какова была основная причина?

Я задаю здесь фактический, исторический вопрос, а не о том, нравится ли это кому-то или это хороший или плохой подход.

Обновление : если бы меня спросили, что делать, я бы сказал - сгенерировать исключение, почти так же, как индексирование массива (несмотря на то, что «старые» языки делали все возможное, как обрабатывать индекс за пределами границ, UB, расширять массив, и т.д).

Это почти всегда то, что вы хотите, и когда это не так, вы можете сделать заполнение самостоятельно.

Основная проблема заключается в ленивой семантике, когда вы не знаете длину при первом запуске zip, поэтому вы не можете просто выбросить исключение в начале. Вам нужно будет сначала вернуть все общие элементы, а затем сгенерировать исключение, которое не будет очень полезным.

Это также вопрос стиля. Императивные программисты привыкли вручную проверять граничные условия повсюду. Функциональные программисты предпочитают конструкции, которые не могут потерпеть неудачу в дизайне Исключения крайне редки. Если у функции есть способ вернуть разумное значение по умолчанию, функциональные программисты примут его. Композиционность - король.

Потому что нет очевидного способа завершить хвост. Любой выбор того, как это сделать, приведет к неочевидному хвосту.

Хитрость заключается в том, чтобы явно удлинить ваш самый короткий список, чтобы он соответствовал длине самого длинного с ожидаемыми значениями.

Если zip сделал это для вас, вы не могли бы знать, какие значения он заполнял интуитивно. Был ли цикл в списке? Это повторило бесполезное значение? Какое среднее значение для вашего типа?

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

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

Хотя помните, что эта и многие другие общие функции стиля FP являются общими, потому что они просты и обобщены, так что вы можете настроить свой код, чтобы использовать их и получить желаемое поведение. Например, в C # вы могли бы просто

IEnumerable<Tuple<T, U>> ZipDefaults(IEnumerable<T> first, IEnumerable<U> second)
{
    return first.Count() < second.Count()
        ? first.Concat(Enumerable.Repeat(default(T), second.Count() - first.Count())).Zip(second)
        : first.Zip(second.Concat(Enumerable.Repeat(default(U), first.Count() - second.count())))
}

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