.net - ¿Puedo confiar en que LINQ ToArray() siempre devuelve una nueva instancia?

Question

Estoy buscando una manera fácil de clonar un IEnumerable<T> para una referencia posterior. El método de extensión ToArray de LINQ parece una forma agradable y concisa de hacer esto.

Sin embargo, no tengo claro si siempre se garantiza la devolución de una nueva instancia de matriz. Varios de los métodos LINQ verifican el tipo real del enumerable, y acceso directo si es posible; por ejemplo, Count() verá si el método implementa ICollection<T> , y si es así, leerá directamente su propiedad Count ; solo itera la colección si es necesario.

Dada la mentalidad de cortocircuito donde es práctico, parece que, si llamo a ToArray() en algo que ya es una matriz, ToArray() podría ToArray() un cortocircuito y simplemente devolver la misma instancia de matriz. Eso técnicamente cumpliría con los requisitos de un método ToArray .

De una prueba rápida, parece que, en .NET 4.0, llamar a ToArray() en una matriz devuelve una nueva instancia. Mi pregunta es, ¿puedo confiar en esto? ¿Se me puede garantizar que ToArray siempre devolverá una nueva instancia, incluso en Silverlight y en futuras versiones de .NET Framework? ¿Hay documentación en algún lugar que sea claro en este punto?

Answer 1

Dado que el método ToArray es interno al marco .NET, no apostaría mi vida en la EM nunca lo cambiaría. Sin embargo, lo que haría es agregar una prueba unitaria que confirme que ToArray devuelve una nueva instancia de matriz.

Assert.AreNotSame(myArray, myArray.ToArray());

De esa manera, si posteriormente cambia las versiones de .NET framework, sabrá automáticamente si la funcionalidad cambia.

Answer 2

Sí, ToArray siempre devolverá una nueva matriz, por lo que hacer que el cambio devuelva un valor existente sería un cambio horrible y estoy absolutamente convencido de que el equipo de .NET no haría esto. Es una cosa importante para poder confiar. Es una pena que no esté documentado :(

Hay muchos comportamientos sutiles en LINQ a Objetos en los que probablemente no vale la pena confiar, pero en este caso es un comportamiento tan masivo que me sorprendería que cambie.

El cortocircuito es excelente cuando no afecta el comportamiento, pero en general, LINQ to Objects es bastante bueno solo para optimizar en casos válidos. Es posible que desee ver las two posts de mi serie Edulinq que cubren la optimización.