array make_unique, proposta originale vs proposta iniziale finale

Question

Stephan T Lavavej per make_unique era N3588

comprendeva le seguenti funzioni:

make_unique<T>(args...) 
make_unique_default_init<T>() 

make_unique<T[]>(n) 
make_unique_default_init<T[]>(n) 
make_unique_value_init<T[]>(n, args...) 
make_unique_auto_size<T[]>(args...) 

Tuttavia, Ricatto d'amore finale, N3656, include solo make_unique (sia forme). Non riesco a trovare alcuna discussione sulle altre forme della funzione. Ho letto the minutes of the Bristol meeting, ma non fanno nemmeno riferimento alla proposta originale.

Perché queste funzioni extra non sono state incluse nella bozza finale?

Answer 1

Ho letto i verbali della riunione di Bristol, ma non fanno nemmeno riferimento alla proposta originale.

I minuti sono accurati. N3588 (ricetta originale, senza Standardese) non è stato discusso in commissione, solo l'N3656 (extra croccante, con standardese) è stato discusso lì. Se non sei stato a una riunione, questo potrebbe sembrare strano, ma quello che succede è che i gruppi di lavoro (Core, Evolution, Library, Library Evolution) e i gruppi di studio (Filesystem, ecc.) Funzionano parallelamente durante la settimana, alla fine conducendo sondaggi di paglia (dove chiunque può votare) per determinare cosa dovrebbe essere portato al comitato completo. Il penultimo giorno, l'intero comitato (più di 100 persone) si riunisce, dove vengono discusse brevemente le mozioni formali, e vengono condotte sondaggi di paglia (in cui solo i membri votanti possono votare). Se qualcuno è preoccupato che le caratteristiche non siano sufficientemente elaborate, o che ci siano problemi di integrazione con altre funzionalità, ecc., Allora questo è discusso qui - ma il comitato non esamina i dettagli microscopici di una proposta. Fondamentalmente se qualcosa è abbastanza controverso da meritarlo, non sopravviverà comunque a un voto, quindi verrà ritirato dalla considerazione per quell'incontro. Poi, l'ultimo giorno, la commissione si riunisce di nuovo, e vengono presi i voti reali (solo membri votanti). In generale, non ci dovrebbero essere sorprese durante i veri voti, dal momento che il giorno prima era una corsa di prova.

I minuti LWG non sono disponibili al pubblico, ma posso dirti cosa è successo. N3588 non conteneva volutamente alcun standardese: quello che ho fatto è stato esplorare lo spazio del design, capire quali nuove espressioni dovremmo imitare e discutere a favore o contro varie cose. Avevo intenzione di ricevere un feedback dal LWG, quindi bozza la standardese per il prossimo meeting (Chicago), poiché scrivere qualcosa di complicato mi richiede molto tempo per essere esattamente corretto (ci vuole più tempo che implementarlo, dal momento che le danze con cura attorno a dettagli di implementazione come SFINAE). Durante la presentazione della proposta, ho spiegato come non ero un grande fan di default-init (che deride come garbage-init), ma avevo delineato come si potesse fare comunque. Ho anche spiegato che avevo imparato di più sui casi di array-init da quando ho scritto la proposta (mentre ricevevo feedback dagli sviluppatori di MS). È interessante notare che il Core Language fornisce garanzie di sequencing per gli elenchi bretelle-init, quindi la nuova X [3] {f(), g(), h()} chiama quelle funzioni da sinistra a destra. Le chiamate di funzione non ottengono quelle garanzie, che (secondo me) ferite mortali tenta di avvolgere array-init come nella mia proposta originale. Esistono modi intelligenti per ottenere le garanzie di sequenziamento con una sintassi utente leggermente diversa e una complessità di implementazione ancora maggiore, che ho spiegato al LWG. A questo punto, volevo davvero eliminare array-init, ed ero tiepido su default-init (che è facile da specificare e implementare, ma lo considero essenzialmente non necessario). La reazione del LWG era che volevano solo le forme più semplici - niente array-init e nemmeno init-default. Sono stato molto felice di sentire questo, e sono stato in grado di scrivere il necessario standardese alla riunione stessa (alle 4 del mattino). Ecco da dove viene N3656. Il LWG ha dato un'altra occhiata a questo, e con un piccolo aggiustamento (cambiando make_unique < T [N] > il tipo di ritorno da vuoto a non specificato, cosa che ho fatto prima che fosse "set in stone") era pronto a portarlo al comitato completo.

Quindi, come avete visto nel verbale, la preoccupazione era che potessimo muoverci troppo velocemente con make_unique. N3588 era in orario di pre-incontro, ma questa era la prima volta che appariva - quasi tutte le proposte richiedevano più di un singolo incontro per passare dalla prima apparizione al movimento formale (la mia prima proposta, i funtori dell'operatore trasparente, era un'eccezione ancora più insolita come appariva e fu votata senza cambiamenti a Portland). A proposito, questa era una preoccupazione totalmente valida. Alla fine, il voto è passato - i membri non devono spiegare i loro voti, ma la mia sensazione era che si trattava di una combinazione tra la proposta di essere molto piccola, nessuno che avesse obiezioni sul contenuto attuale e l'implementazione disponibile.

Ora dovrò pensare a tutte queste cose di nuovo per make_shared!