Funzionalità C # o .Net da escludere supponendo che non sia necessaria la compatibilità con le versioni precedenti? [chiuso]

Metodi anonimi . Penso che tutti siano d'accordo sul fatto che la sintassi del metodo anonimo scelta per C # 2.0 sia complessa e complessa rispetto alla sintassi lambda che abbiamo aggiunto al C # 3.0. È davvero spiacevole avere due sintassi quasi identiche per fare la stessa cosa.

Mi libererei delle raccolte non generiche. Sono un abominio ... e ci sono troppi casi in cui sto usando linq e devo fare qualcosa di simile

var customObjects = container.CustomObjects.Cast<CustomObject>();

Ogni volta che devo farlo, una piccola parte della mia anima muore.

void come tipo . Perché sulla terra è "vuoto" un tipo? Non ha istanze, non ha valori, non puoi usarlo come argomento di tipo generico, tipo di parametro formale, tipo locale, tipo di campo o tipo di proprietà. Non ha significato come tipo; piuttosto, è un dato di fatto su quale effetto ha una chiamata di metodo sullo stack della macchina virtuale. Ma la macchina virtuale è proprio questa: una macchina virtuale. La macchina reale metterà il valore restituito in un registro (tipicamente EAX su x86) e non influenzerà affatto lo stack! Il vuoto come tipo è solo una cattiva idea tutt'intorno.

Peggio: se usato in un tipo di puntatore come in void* , significa qualcosa di completamente diverso di quello che significa quando viene usato come tipo di ritorno. Ora significa "un puntatore a una posizione di archiviazione di tipo sconosciuto", che non ha assolutamente nulla a che fare con il suo significato come "un metodo che non restituisce alcun valore."

Possiamo sostituire void* come un tipo di puntatore con IntPtr . (E void** con IntPtr* e così via.) Possiamo sostituire void come un tipo di ritorno con "Unit", un tipo che ha un valore singolo, vale a dire null. Un'implementazione del CLR potrebbe quindi decidere che una chiamata di funzione digitata in unità potrebbe ottimizzare l'utilizzo dei registri o degli stack in modo appropriato, sapendo che il valore null "restituito" può essere tranquillamente ignorato.

In un mondo del genere non hai più bisogno di delegati separati Func<A, R> e Action<T> . Action<T> è solo Func<T, Unit> .

Covarianza non sicura su matrici di tipo di riferimento . Con la covarianza typesafe su IEnumerable<T> , almeno parte della necessità della covarianza dell'array è andata via. (Se avessimo un'interfaccia di lista di sola lettura covariante, non ne avremmo affatto bisogno.)

L'istruzione vuota ; . A rischio di errore, quasi sempre un errore di battitura, e non ti dà alcun significato aggiunto che non sia già espresso da {} .

L'operatore unario più . Operatore meno utile di tutti i tempi. Se non dovessimo tenerlo per i compatri all'indietro, lo porterei fuori in un batter d'occhio. Chi usa questa cosa, chiunque?

(Chiarimento: l'operatore unario più +x non è l'operatore di preincremento ++x , non l'operatore di postincremento x++ e non l'operatore di aggiunta binario x+y .)

Valore letterale numerico predefinito a double

Per la maggior parte delle app commerciali , decimal è più appropriato comunque ... o forse sarebbe meglio solo rimuovere l'idea di un default e forzare lo sviluppatore per fare effettivamente la scelta.

(Quel "rimuovere l'impostazione predefinita" sarebbe appropriato anche per alcune altre cose. Ad esempio, ho rinunciato a cercare di persuadere tutti che le classi dovrebbero essere sigillate di default, ma sospetto che sia più facile persuadere le persone che loro dovrebbe pensare se la loro nuova classe debba essere chiusa o meno, e renderla esplicita.)

Questa è più una linea guida che una caratteristica, ma penso che sia importante perché è già troppo radicato nelle menti delle persone come la soluzione canonica e migliore:

Il schema ufficiale per implementare IDisposable .

È ingombrante e ci sono modi migliori .

I sapere ci sono grandi differenze tra le varie classi di timer. Ma non potremmo sbarazzarci di uno o due di loro, comunque?

Metodi e tipi di Array e List<T> che sono diventati obsoleti con Linq, ad esempio:

• Array.TrueForAll può essere sostituito con Enumerable.All
• Array.FindAll può essere sostituito con Enumerable.Where
• List<T>.ConvertAll può essere sostituito con Enumerable.Select
• Predicate<T> può essere sostituito con Func<T, bool>
• Converter<T,R> può essere sostituito con Func<T, R>
• IComparer<T> in realtà dovrebbe essere un delegato Func<T, T, int>

Delegati non generici Come le raccolte non generiche, i delegati non generici sono inutili ora che abbiamo serie Func e Action. E avrei tagliato le varianti con tre parametri. Se hai più di tre parametri, crea una struttura e usala come parametro singolo. Dichiarare un delegato specifico per la gestione degli eventi non è molto ASCIUTTO.

Servizi Web asmx

Penso che oggigiorno siano piuttosto obsoleti con WCF.

WinForms
Sarebbe bello non dover navigare tra due piattaforme desktop. WPF è dove stanno andando le cose, quindi è frustrante avere una piena ridondanza a livello di piattaforma.