Open bricelam opened 3 months ago
I'll take this
@BenjaminBrienen This one can be tricky. In same cases it may be possible to just remove the call but there will be cases where the call is there intentionally to change return from whatever to IEnumerable<T>
. And it may be not that easy to determine which case it is.
Good point.
@josefpihrt Could we have 2 code fixes? One that suggests to remove it and another one that suggests AsEnumerable()?
Yes, there can be two fixes, but you still have an issue how to determine which one it is.
Yes, there can be two fixes, but you still have an issue how to determine which one it is.
I was imagining that the user would just pick one of the two suggestions.
Another strategy would be: We could always suggest AsEnumerable()
and then also have a completely separate analyzer that handles unnecessary AsEnumerable()
calls. That second analyzer would be the more difficult one to implement.
We could always suggest AsEnumerable()
Actually, Select(x => x)
is not semantically equivalent to .AsEnumerable()
. Consider this example:
return list.Select(x => x);
If you change it to
return list.AsEnumerable();
Caller will have direct access to list which was not possible before.
RCS1077 should recommend removing
.Select(x => x)
.