What C# features would be removed if backwards compatibility were not an issue? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 9 years ago.

Improve this question

Backwards compatibility is a big concern for language designers, especially when the language is as popular as C#. Over time languages accumulate obsolete features. It's considered good practice to avoid these features, but they are kept in the langage for compatibility with old releases.

Which language features or base class libraries in C# should be removed if backwards compatibility were no开发者_开发技巧t an issue?

I am not asking about features that some developers like and others loathe. I am interested in features that are (pretty much) universally regarded as best-avoided (perhaps because there is now an outright better way of doing the same thing).

---

ArrayList.

There is no point in using it anymore. List<> is way better.

---

I have heard several of the C# designers mention that they regret making arrays covariant.

---

I know this is an obvious answer but any class, property or method marked with the [Obsolete] attribute would probably be the first to be removed.

---

Non-sealed types by default.

---

When implementing IEnumerable<T>, you'll have to implement IEnumerator<T> GetEnumerator() as well System.Collections.IEnumerator GetEnumerator() for backwards compatibility reasons.

---

The ReaderWriterLock class is basically pointless now in favor of the ReaderWriterLockSlim class, which Microsoft themselves say is recommended for all new development.

---

Named attribute constructor parameters.

Currently, you set the named parameters with:

[AttributeUsage(AttributeTargets.Method, Inherited = false, AllowMultiple = true)]

This is from the time of C#1, but now there are object constructors:

new Foo(explicit, values) { Implicit = value }

Which would result in the following Attribute constructor:

[AttributeUsage(AttributeTargets.Method) { Inherited = false, AllowMultiple = true }]

---

The System.IO.Path.InvalidPathChars field. Using it results in a security risk, but there's nothing they can do about it for compatibility reasons.

---

From the BCL's:

1. COM Interop
2. StringCollection (Generic List)
3. StringDictionary (Generic Dictionary)

---

Generic lists (as mentioned by Reshure) including "var". I'm a proponent of explicitly declaring variables.

Edit: I think people are equating "generic lists" with "generics". If you prefer, "untyped collections" such as Hashtable or ArrayList.