4 ms·

That surprises me. If you were calling a method that didn't exist in IEnumerable, why would resharper suggest changing the type to IEnumerable?

keithnz 9y ago
Exactly. The actual suggestions are based on Microsoft Guidelines :- https://msdn.microsoft.com/en-us/library/dn169389%28v=vs.110%29.aspx https://msdn.microsoft.com/en-us/library/dn169389%28v=vs.110...
omgtehlion 9y ago
The method exists in both IEnumerable<T> and Collection<T> (I do not remember exact class, but it was something simple like List`1). The difference is when you use IEnumerable<T> user method (provided as extension, using IEnum) has to call IEnumerator GetEnumerator() and allocate it on a heap. But that collection have its own implementation which works faster than generic one.
- joshjje 9y ago
  Yeah I believe you are talking about enumerating over the interface versus the concrete class? (For others) Most of .NET frameworks generic collections implement the enumerator as a struct which doesnt get allocated on the heap and subsequently garbage collected, but the explicit interfaces implementations use a class which does.
emodendroket 9y ago
Arguably, you might want to specify in some cases. For instance, both List<T> and HashSet<T> implement ICollection<T>.Contains, so code written to the interface will work with either. On the other hand, the HashSet implementation runs in constant time and the list implementation runs in linear time. Depending on what you're doing that might make things a lot slower. So you could certainly make an argument that you should just force the caller to pass in a HashSet in the first place, especially if the method is protected or private.
n4r9 9y ago
I suspect it's more to do with the optimisation of the method. For example, calling List.Count in a tight loop is much faster than IEnumerable. Count. I don't use resharper so don't know if it watches out for this, but no doubt there are plenty of other examples.

keithnz 9y ago

Exactly. The actual suggestions are based on Microsoft Guidelines :- https://msdn.microsoft.com/en-us/library/dn169389%28v=vs.110%29.aspx https://msdn.microsoft.com/en-us/library/dn169389%28v=vs.110...

omgtehlion 9y ago

The method exists in both IEnumerable<T> and Collection<T> (I do not remember exact class, but it was something simple like List`1). The difference is when you use IEnumerable<T> user method (provided as extension, using IEnum) has to call IEnumerator GetEnumerator() and allocate it on a heap. But that collection have its own implementation which works faster than generic one.

joshjje 9y ago
Yeah I believe you are talking about enumerating over the interface versus the concrete class? (For others) Most of .NET frameworks generic collections implement the enumerator as a struct which doesnt get allocated on the heap and subsequently garbage collected, but the explicit interfaces implementations use a class which does.

emodendroket 9y ago

Arguably, you might want to specify in some cases. For instance, both List<T> and HashSet<T> implement ICollection<T>.Contains, so code written to the interface will work with either. On the other hand, the HashSet implementation runs in constant time and the list implementation runs in linear time. Depending on what you're doing that might make things a lot slower. So you could certainly make an argument that you should just force the caller to pass in a HashSet in the first place, especially if the method is protected or private.

n4r9 9y ago

I suspect it's more to do with the optimisation of the method. For example, calling List.Count in a tight loop is much faster than IEnumerable. Count. I don't use resharper so don't know if it watches out for this, but no doubt there are plenty of other examples.