Well, I’ve just discovered it does : SequenceEqual<TSource> (see http://msdn2.microsoft.com/en-us/library/bb3420...) enumerates the elements and compares them.
The main difference with IsEqualTo<TSource> is that it throws exceptions whenever one of the IEnumerable<T> is null.

However, the names of the methods are consistent :
- IsEqualTo compares the containers and their content if any.
- SequenceEqual compares the content (the sequence). Therefore the containers are supposed to exists (ie not null)

The implementation of method SequenceEqual (seen through Reflector) :
- does not use local vars. As a result, there is one more call to MoveNext than in IsEqualTo, but the code looks straightforward in my opinion.
- reminds me you could remove try/finally and replace that with using statements. It then behaves the same but it’s much more readable. (Haven’t seen that !.. I must still be disturbed by the fact IEnumerator<T> implements IDisposable…)

Well, I’ve just discovered it does : SequenceEqual<TSource> (see http://msdn2.microsoft.com/en-us/library/bb342073.aspx) enumerates the elements and compares them.
The main difference with IsEqualTo<TSource> is that it throws exceptions whenever one of the IEnumerable<T> is null.

However, the names of the methods are consistent :
- IsEqualTo compares the containers and their content if any.
- SequenceEqual compares the content (the sequence). Therefore the containers are supposed to exists (ie not null)

The implementation of method SequenceEqual (seen through Reflector) :
- does not use local vars. As a result, there is one more call to MoveNext than in IsEqualTo, but the code looks straightforward in my opinion.
- reminds me you could remove try/finally and replace that with using statements. It then behaves the same but it’s much more readable. (Haven’t seen that !.. I must still be disturbed by the fact IEnumerator<T> implements IDisposable…)

Two more remarks and I’m done/gone (and I stop bugging you !) :
A- You can remove the catch block. A try/finally is more than enough in that case.
B- Don’t you want to return true also when value == compareList ? (If you do you can replace line 15 with if(value == compareList) )

Now you’ve provided your readers with an “IsEqualTo” method, I propose an exercise for their spare time : implement “StartsWith” (easy) and “EndsWith” (ouch ! seems harder) extension methods on IEnumerable<> !

Regards

Thanks for your help with this, and for your patience in getting your point through! I added in some exception handling to dispose of resources in this revision too.

I’m ok to say “fi” != “fish” (no matter what order).
However, did you try “fish”.IsEqualTo(”fis”); ? [or to take my example "123".IsEqualTo("12");]
I did with the latest version of the code of your post above (in .NET2.0; I removed the “this” in the method parameters). It returns true.

When the enumerators “lengths” differ by 1 element and the extension method is run on the “bigger” enumerator, the problem arises. The sequence is the following :
A- looping on common elements. Ok.
B- enumerator2 runs out of elements (MoveNext == false) while enumerator1 points to the last element of the “bigger” enumerator.
C- the while condition is thus false. Moving to return statement.
D- enumerator2.MoveNext still remains false.
E- enumerator1.MoveNext becomes false because it’s now pointing after the last element. We’ve sort of ignored the last element of enumerator1 (we made twice MoveNext on it : at steps B then E).
F- Return statement thus returns true.

To solve this issue you :
- either have to MoveNext() transactionnally both enumerators in the while condition. I don’t know how to do this properly in an elegant way…
- or have to store the result of the MoveNext() as I did in the previous code I posted. These values are the states of the last calls to MoveNext(). I can therefore use them in the return statement, without “MoveNexting” the enumerator…

As an alternative to my code, you may also want to remove additional MoveNext() calls in the body. This gives the following code (we have here one single call MoveNext for each enumerator) :

public static bool IsEqualTo<T>(IEnumerable<T> value, IEnumerable<T> compareList, IEqualityComparer<T> comparer)
{
/* begin of method goes here */
else
{
IEnumerator<T> enumerator1 = value.GetEnumerator();
IEnumerator<T> enumerator2 = compareList.GetEnumerator();

bool enum1HasValue;
bool enum2HasValue;
while ((enum1HasValue=enumerator1.MoveNext()) & (enum2HasValue=enumerator2.MoveNext()))
{
if (!comparer.Equals(enumerator1.Current, enumerator2.Current))
{
return false;
}
}
return !(enum1HasValue || enum2HasValue);
}
}

Note that this last snippet uses a non-short-circuiting & operator in the while condition. If you short-circuit with a &&, you’ll have a bad value in enum2HasValue whenever enumerator1 first runs out of elements.
However I only recommand this implementation if it’s well documented and not subjet to frequent code review, because the use of the non-short-circuiting & operator may lead to confusion or anti-optimisation (”hey, man, && is cooler, because it doesn’t evaluate more than needed !”).
I personally wouldn’t use such a cryptic implementation : the performance should be the equivalent (if not same), and readability decreases.

Two more remarks and I’m done/gone (and I stop bugging you !) :
A- You can remove the catch block. A try/finally is more than enough in that case.
B- Don’t you want to return true also when value == compareList ? (If you do you can replace line 15 with if(value == compareList) )

Now you’ve provided your readers with an “IsEqualTo” method, I propose an exercise for their spare time : implement “StartsWith” (easy) and “EndsWith” (ouch ! seems harder) extension methods on IEnumerable<> !

Regards

Both the following tests pass:

[Test]
public void TestDifferentLengthStrings()
{
string a1 = “fi”;
string a2 = “fish”;

Assert.IsFalse(a1.IsEqualTo(a2));
}

[Test]
public void TestDifferentLengthStringsReverse()
{
string a1 = “fish”;
string a2 = “fi”;

Assert.IsFalse(a1.IsEqualTo(a2));
}

Thanks for your help with this, and for your patience in getting your point through! I added in some exception handling to dispose of resources in this revision too.