Isn't Cast<T> implementation against Linq's immutable style?
c#, immutability, linq
Solution
The examples you give, that manipulating the source array affects the output of the enumeration, is actually due to the deferred execution. So they don't suggest deferred execution is not happening.
It makes no difference if you get a reference to the original list, or to the `CastIterator`. The latter will lazily evaluate the source, so changes are reflected in both cases.
If C# were a pure functional language, Linq could be lazy (deferred) and would return an iteration that would not change over time.
But C# is not a pure functional language.
The Linq team had to choose, and implemented the lazy part. Immutability would be more costly to enforce within Linq. But if you want immutability, you can get it: just stop changing the source, or make snapshots using `ToArray()` when appropriate.
Problem
This is how `Cast<T>` is implemented in the framework: ``` public static IEnumerable<TResult> Cast<TResult>(this IEnumerable source) { IEnumerable<TResult> enumerable = source as IEnumerable<TResult>; if (enumerable != null) { return enumerable; //the culprit } return Enumerable.CastIterator<TResult>(source); } ``` The problem I see is that `Cast<T>` returns the actual enumerable itself if some criterion is met. For instance this shouldn't happen: ``` var x = new List<string> { "1" }; var y = x.Cast<string>(); x.Add("2"); //reflects in y "immediately", since they are the same reference. ``` Or may be a more practical example: ``` object[] x = new[] { "1" }; var y = x.Cast<string>(); x[0] = "2"; //reflects in y "immediately", since they are the same reference. ``` The documentation page even says: This method is implemented by using deferred execution., but not really in every case (as shown above). Similarly I can think of `AsEnumerable` as another culprit which returns itself. A situation where it can trip: ``` var x = new List<string> { "1" }; //data source var y = x.Cast<string>(); //query ((List<string>)y).Add("2"); //did something with the query // Whoa, got the data source itself changed by tinkering the query ``` Questions: Don't the two methods `AsEnumerable` and `Cast` violate the functional nature of Linq extension methods? May be I'm reading some guideline wrongly? Are there more similar extension methods in `System.Linq` namespace which returns itself? Ok guys, I supposed every linq method would produce a new sequence upon enumeration, which is the not the case here. May be I need not think like that. But it seems there was a confusion regarding deferred execution. I expected a change to data source will be reflected in the `IEnumerable<T>` represented by the linq query only upon execution (I mean enumeration) of the query. For example, consider the below example: ``` var x = new List<int> { 1 }; var y = x.Cast<SomeEnum>(); x.Add(2); //at this stage the change to x is not reflected in y yet ``` In the above example, if I add a new element to `x`, `y` still points to a query, and the change to `x` is not reflected in `y`. I considered that as deferred execution, in the sense, one has to enumerate it to see the changes. Where as in the previous examples, the change was immediately reflected in `y`. So I thought it wasn't really deferred execution. Going by the answers here, my thinking was wrong.