[angrysaki]

>Also, the design of this this method doesn't seem to make much difference to me anyways:

``` var strs = source.SelectNotNull(it => it); ```

vs

``` var strs = source.Where(it => it != null); ```

Wouldn't the first be IEnumerable<TR> and the second be IEnumerable<TR?>

I imagine that's the main driver for creating SelectNotNull, so that you get the nonnullable type out of the Linq query

[mrcsharp]

> I imagine that's the main driver for creating SelectNotNull

Sure. And now we are fighting the compiler and in the process writing less efficient code.

The compiler gives us a way to deal with this situation. It is all about being absolutely clear with intentions. Yes, Where(..) in my example would return IEnumerable<TR?> but then in subsequent code I can tell the compiler that I know for a fact that TR? is actually TR by using the null forgiving operator (!).

[angrysaki]

>The compiler gives us a way to deal with this situation. It is all about being absolutely clear with intentions. Yes, Where(..) in my example would return IEnumerable<TR?> but then in subsequent code I can tell the compiler that I know for a fact that TR? is actually TR by using the null forgiving operator (!).

I guess that seems way less clear with intentions to me. If I have an array of potentially null types and I want to filter out the not nulls, I'd much rather have an operation that returns a T[] vs a T?[].

I should also note that I also have a "IEnumerable<T> WhereNotNull(IEnumerable<T>?)" function in my codebase, but I implemented it using a foreach/yield which doesn't suffer from the extra Cast<>()