Includere funzionalità nelle librerie standard vs nella lingua stessa

Per quote Eric Lippert , che ha lavorato al team di progettazione C # e chi parafrasando e espandendo alcune parole con Eric Gunnerson , che ha lavorato anche alla squadra C #:

And (2) just being a good feature is not enough. Features have to be so compelling that they are worth the enormous dollar costs of designing, implementing, testing, documenting and shipping the feature. They have to be worth the cost of complicating the language and making it more difficult to design other features in the future.

(sottolinea il signor Lippert)

Lasciare una lingua così com'è è gratis. Free è un vantaggio molto grande.

I designer di lingue tendono a essere prudenti e con buone ragioni. Un errore può azzannarli per un tempo molto lungo a causa della necessità di mantenere la retrocompatibilità. Inoltre, la compatibilità all'indietro è dolorosa, basta guardare la transizione da Python 2 a Python 3.

Quindi, se vuoi introdurre una modifica a una lingua, devi avere una giustificazione molto strong. A mio parere, la rimozione di una o più righe (a seconda di come è organizzata la libreria standard e di ciò che serve) per file è un vantaggio piuttosto piccolo, specialmente considerando che quelle linee possono essere inserite banalmente da molti IDE e persino testo editor, spesso in un modo più generale che può includere non solo la libreria standard, ma anche librerie personalizzate e di terze parti.

E qualsiasi tempo e denaro che i designer di lingua impiegano per duplicare le funzionalità minori degli editor di testo, sia quando lo implementano inizialmente, o lavorando in un secondo momento, è tempo e denaro che non spendono per altre funzionalità.

A volte però, i progettisti decideranno che fare ciò che stai suggerendo vale il costo. Common Lisp, ad esempio, rende l'intera libreria standard disponibile per impostazione predefinita, senza richiedere alcun tipo di istruzione import .

Penso che il tipo divariant di C ++ al 17% offra un aspetto interessante del problema della lingua rispetto alla libreria.

Il tipo di C ++ 17 variant ha avuto una storia lunga e semi tortuosa nel suo sviluppo. Il grosso problema è stato come affrontare il lancio di costruttori durante l'assegnazione / collocazione in un oggetto live variant .

L'ovvio desiderio sarebbe quello di fornire la strong garanzia di eccezione: se il nuovo oggetto getta durante copia / sposta / installa in variant , allora variant rimane invariato. Ma l'implementazione ha problemi. Il sizeof desiderato per un variant è quello di un equivalente union + a char per discriminare al loro interno.

Ciò significa che se si assegna / si inserisce in una variante, devono avvenire 2 cose: distruggere il vecchio valore, quindi costruire il nuovo valore al suo posto. È il n. 2 che fallisce; il vecchio valore è andato . Non puoi riprenderlo.

Potresti provare a giocare, come spostare il vecchio valore in un temporaneo, quindi spostarlo indietro se la costruzione del nuovo fallisce. Ma le operazioni di spostamento possono lanciare e ci sono persino tipi di libreria standard con mosse di lancio. Puoi provare a raddoppiare i dati (memorizzare i dati 2x, in modo da avere sempre un margine temporaneo), o anche allocare memoria come boost::variant , ma quelli sono stati considerati inaccettabili dal comitato.

Per un variant basato sulla lingua, questo ovviamente non sarebbe un problema. Lo standard dichiarerebbe semplicemente da fiat che offre la strong garanzia di eccezione e che è dimensionato in modo appropriato, non alloca memoria, ecc. I compilatori dovrebbero usare la magia del compilatore per farlo funzionare.

Tuttavia ... e se potessimo semplicemente esporre quel "magic del compilatore" come una caratteristica del linguaggio di prima classe ? Ad esempio, questa proposta suggerisce un modo per fare una mossa efficace costruttori che non lanciano. In questo modo, ora possiamo utilizzare il metodo temporaneo per implementare variant .

Questo ti offre la maggior parte se non tutti i vantaggi di una lingua variant , ma anche ti fornisce strumenti che puoi usare per rendere più efficiente l'altro codice.

Se cerchi di inserire qualsiasi cosa nella lingua, ciò che scoprirai è che farai dipendere eccessivamente gli utenti dalla lingua, piuttosto che usare la lingua per dare agli utenti gli strumenti per costruire ciò di cui hanno bisogno. Questo è particolarmente importante per un linguaggio di basso livello (er) come C ++.

Perché rende più semplice aggiungere ulteriori funzionalità alla libreria standard senza violare il codice esistente degli utenti - e i comitati linguistici odiano il codice di interruzione.

Inserendo una funzione in una libreria separata che deve essere inclusa / importata, riduci le probabilità che qualsiasi nuova funzionalità causi conflitti di nomi con classi o funzioni che il programmatore ha già scritto da sé.

Questo è particolarmente vero se la tua biblioteca ha una convenzione di denominazione ragionevole.