LINQ: No Any vs All Don't

Spesso voglio verificare se un valore fornito corrisponde a uno in un elenco (ad es. Durante la convalida):

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

Di recente, ho notato ReSharper che mi chiede di semplificare queste query per:

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

Ovviamente, questo è logicamente identico, forse leggermente più leggibile (se hai fatto molta matematica), la mia domanda è: questo si traduce in un hit da prestazione?

Sembra che dovrebbe (cioè .Any()sembra cortocircuito, mentre .All()sembra che non lo sia), ma non ho nulla per dimostrarlo. Qualcuno ha una conoscenza più approfondita se le query risolveranno lo stesso o se ReSharper mi sta portando fuori strada?

Implementazione di Allsecondo ILSpy (come in realtà sono andato e guardato, piuttosto che "bene, quel metodo funziona un po 'come ..." Potrei fare se discutessimo della teoria piuttosto che dell'impatto).

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

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

Naturalmente, potrebbe esserci qualche sottile differenza nell'IL prodotta. Ma no, no non c'è. L'IL è praticamente lo stesso, ma per l'ovvia inversione di restituire true su match predicato rispetto a restituire false su predication mismatch.

Ovviamente questo è linq-per-oggetti. È possibile che alcuni altri provider linq trattino uno molto meglio dell'altro, ma se così fosse, è praticamente casuale quale ottenga l'implementazione più ottimale.

Sembrerebbe che la regola scenda solo a qualcuno che if(determineSomethingTrue)si sente più semplice e più leggibile di if(!determineSomethingFalse). E in tutta onestà, penso che abbiano un po 'di senso nel fatto che trovo spesso if(!someTest)confuso * quando c'è un test alternativo di uguaglianza e complessità uguali che tornerebbe vero per la condizione su cui vogliamo agire. Eppure, personalmente non trovo nulla che favorisca l'una rispetto all'altra delle due alternative che dai, e forse mi spingerei leggermente verso la prima se il predicato fosse più complicato.

* Non confuso come in non capisco, ma confuso come in temo che ci sia qualche sottile motivo per la decisione che non capisco, e ci vogliono alcuni salti mentali per rendersi conto che "no, hanno appena deciso di fare in quel modo, aspetta di nuovo cosa stavo guardando questo codice? ... "

Potresti trovare questi metodi di estensione che rendono il tuo codice più leggibile:

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

Ora invece del tuo originale

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

potresti dire

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

Entrambi avrebbero prestazioni identiche perché entrambi arrestano l'enumerazione dopo che è possibile determinare il risultato: Any()sul primo elemento il predicato passato valuta truee All()sul primo elemento al quale il predicato valuta false.

All cortocircuiti sul primo non-match, quindi non è un problema.

Un'area di sottigliezza è quella

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

È vero. Tutti gli elementi nella sequenza sono pari.

Per ulteriori informazioni su questo metodo, consultare la documentazione di Enumerable.All .

All()determina se tutti gli elementi di una sequenza soddisfano una condizione.
Any()determina se qualsiasi elemento di una sequenza soddisfa la condizione.

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

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

Secondo questo link

Qualsiasi: verifica almeno una corrispondenza

Tutti: controlla che tutti corrispondano

Come altre risposte hanno ben coperto: non si tratta di prestazioni, ma di chiarezza.

C'è un ampio supporto per entrambe le opzioni:

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

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

Ma penso che questo potrebbe ottenere un supporto più ampio :

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

Semplicemente calcolare il booleano (e nominarlo) prima di negare qualsiasi cosa mi chiarisce molto nella mente.

Se dai un'occhiata alla fonte Enumerable vedrai che l'implementazione di Anyed Allè abbastanza vicina:

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

Non è possibile che un metodo sia significativamente più veloce dell'altro poiché l'unica differenza risiede in una negazione booleana, quindi preferisci la leggibilità rispetto alle vincite con prestazioni false.