LINQ: nem todos vs todos não

Muitas vezes, quero verificar se um valor fornecido corresponde a um em uma lista (por exemplo, ao validar):

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

Recentemente, notei o ReSharper me pedindo para simplificar essas consultas para:

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

Obviamente, isso é logicamente idêntico, talvez um pouco mais legível (se você fez muita matemática), minha pergunta é: isso resulta em um desempenho atingido?

Parece que deveria (ou seja, .Any()soa como um curto-circuito, enquanto .All()parece que não), mas não tenho nada para substanciar isso. Alguém tem um conhecimento mais profundo sobre se as consultas resolverão o mesmo ou se o ReSharper está me desviando?

Implementação de Allacordo com o ILSpy (como na verdade eu fui e olhei, em vez do "bem, esse método funciona um pouco como ..." eu poderia fazer se estivéssemos discutindo a teoria e não o impacto).

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;
}

Implementação de Anyacordo com 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;
}

Obviamente, pode haver alguma diferença sutil na IL produzida. Mas não, não, não há. O IL é praticamente o mesmo, mas pela inversão óbvia de retornar true na correspondência de predicado versus retornar falso na incompatibilidade de predicado.

Isso é linq-for-objects, é claro. É possível que algum outro provedor de linq trate um muito melhor que o outro, mas se esse for o caso, é bem aleatório qual deles obteve a implementação mais ideal.

Parece que a regra se resume apenas a alguém que se sente if(determineSomethingTrue)mais simples e mais legível do que if(!determineSomethingFalse). E, para ser sincero, acho que eles têm um certo ponto em que muitas vezes acho if(!someTest)confuso * quando há um teste alternativo de igual verbosidade e complexidade que retornaria verdadeiro para a condição em que queremos agir. No entanto, realmente, pessoalmente, não encontro nada a favor de uma das outras alternativas que você oferece, e talvez se inclinasse levemente em relação à primeira se o predicado fosse mais complicado.

* Não é confuso como em Eu não entendo, mas confuso como em Eu me preocupo que haja alguma razão sutil para a decisão que eu não entendo, e são necessários alguns saltos mentais para perceber que "não, eles apenas decidiram fazer dessa forma, espere o que eu estava olhando para este pedaço de código novamente? ... "

Você pode encontrar esses métodos de extensão para tornar seu código mais legível:

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);
}

Agora, em vez do seu original

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

você poderia dizer

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

Ambos teriam desempenho idêntico porque ambos param a enumeração após a determinação do resultado - Any()no primeiro item que o predicado passado avalia truee All()no primeiro item que o predicado avalia false.

All curto-circuitos no primeiro non-match, por isso não é um problema.

Uma área de sutileza é que

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

É verdade. Todos os itens da sequência são pares.

Para saber mais sobre esse método, consulte a documentação de Enumerable.All .

All()determina se todos os elementos de uma sequência satisfazem uma condição.
Any()determina se algum elemento de uma sequência satisfaz a condição.

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

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

De acordo com este link

Qualquer - verifica se há pelo menos uma correspondência

Tudo - verifica se todos correspondem

Como outras respostas foram bem abordadas: não se trata de desempenho, é de clareza.

Há amplo suporte para as duas opções:

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

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

Mas acho que isso pode obter um suporte mais amplo :

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

Simplesmente calcular o booleano (e nomeá-lo) antes de negar qualquer coisa esclarece muito isso.

Se você der uma olhada na fonte Enumerable, verá que a implementação de Anye Allé bem próxima:

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;
}

Não há como um método ser significativamente mais rápido que o outro, pois a única diferença está em uma negação booleana; portanto, prefira a legibilidade do que a falsa vitória no desempenho.