LINQ: не все против всех не

Часто я хочу проверить, соответствует ли предоставленное значение одному в списке (например, при проверке):

if (!acceptedValues.Any(v => v == someValue))
{
    // exception logic
}

Недавно я заметил, что ReSharper просит меня упростить эти запросы:

if (acceptedValues.All(v => v != someValue))
{
    // exception logic
}

Очевидно, что это логически идентично, возможно, немного более читабельно (если вы много занимались математикой), мой вопрос: приводит ли это к снижению производительности?

Такое чувство, что оно должно (то есть .Any()звучит так, как будто оно короткое замыкание, тогда как .All()звучит так , как будто это не так), но мне нечем это обосновать. У кого-нибудь есть более глубокие знания относительно того, разрешат ли запросы то же самое, или ReSharper вводит меня в заблуждение?

Реализация в Allсоответствии с ILSpy (как я на самом деле пошел и посмотрел, а не «ну, этот метод работает немного как ...» я мог бы сделать, если бы мы обсуждали теорию, а не влияние).

public static bool All<TSource>(this IEnumerable<TSource> source, Func<TSource, bool> predicate)
{
    if (source == null)
    {
        throw Error.ArgumentNull("source");
    }
    if (predicate == null)
    {
        throw Error.ArgumentNull("predicate");
    }
    foreach (TSource current in source)
    {
        if (!predicate(current))
        {
            return false;
        }
    }
    return true;
}

Реализация Anyсогласно ILSpy:

public static bool Any<TSource>(this IEnumerable<TSource> source, Func<TSource, bool> predicate)
{
    if (source == null)
    {
        throw Error.ArgumentNull("source");
    }
    if (predicate == null)
    {
        throw Error.ArgumentNull("predicate");
    }
    foreach (TSource current in source)
    {
        if (predicate(current))
        {
            return true;
        }
    }
    return false;
}

Конечно, может быть небольшая разница в произведенном IL. Но нет, нет, нет. IL в значительной степени такой же, но для очевидной инверсии возврата true при совпадении предикатов и возврата false при несовпадении предикатов.

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

Казалось бы, правило сводится исключительно к тому, кто чувствует себя if(determineSomethingTrue)проще и понятнее, чем if(!determineSomethingFalse). И, честно говоря, я думаю, что у них есть некоторая точка в том, что меня часто if(!someTest)смущает *, когда есть альтернативный критерий равной многословности и сложности, который вернул бы значение true для условия, в котором мы хотим действовать. Тем не менее, на самом деле, я лично не нахожу ничего, чтобы отдавать предпочтение одной из двух альтернатив, которые вы предоставляете, и, возможно, очень немного склонялся бы к первой, если бы предикат был более сложным.

* Не сбивающий с толку, поскольку я не понимаю, но сбивающий с толку, поскольку я беспокоюсь, что есть некая тонкая причина для решения, которое я не понимаю, и требуется несколько умственных пропусков, чтобы понять, что «нет, они просто решили сделать так, подожди, что я снова посмотрел на этот кусочек кода? ... "

Возможно, эти методы расширения сделают ваш код более читабельным:

public static bool None<TSource>(this IEnumerable<TSource> source)
{
    return !source.Any();
}

public static bool None<TSource>(this IEnumerable<TSource> source, 
                                 Func<TSource, bool> predicate)
{
    return !source.Any(predicate);
}

Теперь вместо твоего оригинала

if (!acceptedValues.Any(v => v == someValue))
{
    // exception logic
}

ты мог бы сказать

if (acceptedValues.None(v => v == someValue))
{
    // exception logic
}

Оба будут иметь одинаковую производительность, потому что оба останавливают перечисление после того, как может быть определен результат - Any()по первому элементу переданный предикат оценивается trueи All()по первому элементу, по которому оценивается предикат false.

All короткие замыкания при первом несовпадении, так что это не проблема.

Одна область тонкости заключается в том, что

 bool allEven = Enumerable.Empty<int>().All(i => i % 2 == 0); 

Правда. Все элементы в последовательности являются четными.

Подробнее об этом методе см. В документации по Enumerable.All .

All()определяет, все ли элементы последовательности удовлетворяют условию.
Any()определяет, удовлетворяет ли какой-либо элемент последовательности условию.

var numbers = new[]{1,2,3};

numbers.All(n => n % 2 == 0); // returns false
numbers.Any(n => n % 2 == 0); // returns true

По этой ссылке

Любой - Проверяет хотя бы одно совпадение

Все - Проверяет, что все совпадают

Как и другие ответы хорошо освещены: речь идет не о производительности, а о ясности.

Существует широкая поддержка для обоих ваших вариантов:

if (!acceptedValues.Any(v => v == someValue))
{
    // exception logic
}

if (acceptedValues.All(v => v != someValue))
{
    // exception logic
}

Но я думаю, что это может обеспечить более широкую поддержку :

var isValueAccepted = acceptedValues.Any(v => v == someValue);
if (!isValueAccepted)
{
    // exception logic
}

Простое вычисление логического значения (и присвоение ему имени) перед отрицанием чего-либо многое проясняет в моей памяти.

Если вы посмотрите на источник Enumerable, вы увидите, что реализация Anyи Allдовольно близка:

public static bool Any<TSource>(this IEnumerable<TSource> source, Func<TSource, bool> predicate) {
    if (source == null) throw Error.ArgumentNull("source");
    if (predicate == null) throw Error.ArgumentNull("predicate");
    foreach (TSource element in source) {
        if (predicate(element)) return true;
    }
    return false;
}

public static bool All<TSource>(this IEnumerable<TSource> source, Func<TSource, bool> predicate) {
    if (source == null) throw Error.ArgumentNull("source");
    if (predicate == null) throw Error.ArgumentNull("predicate");
    foreach (TSource element in source) {
        if (!predicate(element)) return false;
    }
    return true;
}

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