The array interface has several problems. Firstly, it is not as type safe as other collection types. Consider this example:

 object[] x = new string[]{"a", "b", "c"}; x[2] = new DateTime(); 

This will compile correctly but give you a run-time exception. Usually you would expect code to be type safe as long as there is no explicit casting, but arrays have a specific weakness which is not shared by other types. If you had used some of the other collection types or interfaces, the error would have been detected at compile time (for example you can't assign a List<string> to a variable of type List<object>).

Secondly, arrays are a weird combination of mutable and immutable: You can replace elements, but you cant add or remove elements. This is almost never a useful contract. Either you want a collection to be fully immutable or you want it to be fully mutable.

You usually want one of:

• IEnumerable<T> - immutable, sequential access
• IReadOnlyList<T> - immutable, random access to elements
• IList<T> - mutable

Arrays are often fine as the implementation exposed as a IEnumerable<T> or IReadOnlyList<T> since those interfaces protect against the type-safety issue. But there is an additional issue with exposing an array as IList<T>: Arrays actually implement this interface, but will throw a runtime exception if you attempt to add or remove elements. So again it gives you run-time errors instead of compile-time errors.

In short, arrays are not as type safe as other collection types.

The array interface has several problems. Firstly, it is not as type safe as other collection types. In C# you expect type errors to be detected at compile time. Type errors at runtime usually only occur when using explicit casting which is well known to be risky. But updating an array can give you runtime type errors even though the code looks perfectly fine and does not use explicit casting.

The issue arise because the way C# handles array subtyping is unsound. If for example Button is a subtype of Control, then C# also considers Button[] a subtype of Control[]. But this is not a sound assumption! A fundamental tenet of subtyping is that any operation you can do on a type, you can do on a subtype. But you can insert any control in Control[] but you can only insert buttons in Button[].

For example:

Button[] widgets = new Button[7]; Frizzle(widgets);   void Frizzle(Control[] widgets) {   widgets[1] = new Textbox(); } class Control {} class Button : Control; class Textbox: Control; 

This code will compile fine, but fail with an ArrayTypeMismatchException at runtime even though there is no casting involved. 

If you had used some of the other collection types or interfaces, the error would have been detected at compile time. The runtime error is unique to arrays.

Secondly, arrays are a weird combination of mutable and immutable: You can replace elements, but you cant add or remove elements. This is almost never a useful contract. Either you want a collection to be fully immutable or you want it to be fully mutable.

You usually want one of:

• IEnumerable<T> - immutable, sequential access
• IReadOnlyList<T> - immutable, random access to elements
• IList<T> - mutable

Arrays are often fine as the implementation exposed as a IEnumerable<T> or IReadOnlyList<T> since those interfaces protect against the type-safety issue. But there is an additional issue with exposing an array as IList<T>: Arrays actually implement this interface, but will throw a runtime exception if you attempt to add or remove elements. So again it gives you run-time errors instead of compile-time errors.

In short, arrays are not as type safe as other collection types.

The array interface has two big problems. The first is it is not as type safe as other collection types. Consider this example:

 object[] x = new string[]{"a", "b", "c"}; x[2] = new DateTime(); 

This will compile correctly but give you a run-time exception. Usually you would expect code to be type safe as long as there is no explicit casting, but arrays have a specific weakness which is not shared by other types. If you had used some of the other collection types or interfaces, the error would have been detected at compile time (for example you can't assign a List<string> to a variable of type List<object>).

Secondly, arrays are a weird combination of mutable and immutable: You can replace elements, but you cant add or remove elements. This is almost never a useful contract. Either you want a collection to be fully immutable or you want it to be fully mutable.

The array interface has several problems. Firstly, it is not as type safe as other collection types. Consider this example:

 object[] x = new string[]{"a", "b", "c"}; x[2] = new DateTime(); 

This will compile correctly but give you a run-time exception. Usually you would expect code to be type safe as long as there is no explicit casting, but arrays have a specific weakness which is not shared by other types. If you had used some of the other collection types or interfaces, the error would have been detected at compile time (for example you can't assign a List<string> to a variable of type List<object>).

Secondly, arrays are a weird combination of mutable and immutable: You can replace elements, but you cant add or remove elements. This is almost never a useful contract. Either you want a collection to be fully immutable or you want it to be fully mutable.

You usually want one of:

• IEnumerable<T> - immutable, sequential access
• IReadOnlyList<T> - immutable, random access to elements
• IList<T> - mutable

Arrays are often fine as the implementation exposed as a IEnumerable<T> or IReadOnlyList<T> since those interfaces protect against the type-safety issue. But there is an additional issue with exposing an array as IList<T>: Arrays actually implement this interface, but will throw a runtime exception if you attempt to add or remove elements. So again it gives you run-time errors instead of compile-time errors.

In short, arrays are not as type safe as other collection types.