J'ai lu le procès-verbal de la réunion de Bristol, mais il ne fait même pas référence à la proposition initiale.
Le procès-verbal est exact. N3588 (recette originale, sans Standardese) n'a pas été discuté en comité plénier, seul N3656 (extra croustillant, avec Standardese) y a été discuté. Si vous n'avez jamais assisté à une réunion, cela peut sembler étrange, mais ce qui se passe, c'est que les groupes de travail (Core, Evolution, Library, Library Evolution) et les groupes d'étude (Filesystem, etc.) travaillent en parallèle pendant la semaine, en procédant éventuellement à des sondages (où tout le monde peut voter) pour déterminer ce qui doit être présenté au comité plénier. L'avant-dernier jour, le comité au complet (plus de 100 personnes) se réunit, où les motions formelles sont brièvement discutées, et les sondages (où seuls les membres votants peuvent voter) sont effectués. Si quelqu'un craint que les fonctionnalités ne soient pas assez développées, ou qu'il y ait des problèmes d'intégration avec d'autres fonctionnalités, etc., cela est discuté ici - mais le comité complet n'examine pas les détails microscopiques d'une proposition. En fait, si une proposition est suffisamment controversée pour justifier un tel examen, elle ne survivra de toute façon pas à un vote et sera donc retirée de l'ordre du jour de cette réunion. Le dernier jour, l'ensemble du comité se réunit à nouveau et les vrais votes ont lieu (uniquement pour les membres votants). En général, il ne devrait pas y avoir de surprises lors des votes réels, étant donné que la veille a servi de test.
Le procès-verbal du GTL n'est pas accessible au public, mais je peux vous dire ce qui s'est passé. N3588 ne contenait délibérément pas de langage standard - ce que j'y ai fait, c'est explorer l'espace de conception, déterminer quelles nouvelles expressions nous devrions imiter, et argumenter pour ou contre diverses choses. J'avais prévu de recevoir les commentaires du LWG, puis de rédiger un projet de langage standard pour la réunion suivante (Chicago), car écrire quelque chose de compliqué me prend beaucoup de temps (plus de temps que de l'implémenter réellement, car le langage standard contourne soigneusement les détails d'implémentation tels que SFINAE). En présentant la proposition, j'ai expliqué que je n'étais pas un grand fan de default-init (que je tourne en dérision sous le nom de garbage-init), mais que j'avais décrit comment cela pouvait être fait de toute façon. J'ai également expliqué que j'en avais appris plus sur les cas de array-init depuis que j'ai écrit la proposition (tout en recevant des commentaires des développeurs de MS). Il est intéressant de noter que le langage de base fournit des garanties de séquencement pour les listes d'entrées accolées, de sorte que new X[3]{ f(), g(), h() } appelle ces fonctions de gauche à droite. Les appels de fonction ne bénéficient pas de ces garanties, ce qui (à mon avis) blesse mortellement les tentatives d'envelopper array-init comme dans ma proposition originale. Il existe des moyens astucieux d'obtenir les garanties de séquencement avec une syntaxe utilisateur légèrement différente et une complexité d'implémentation encore plus grande, ce que j'ai expliqué au LWG. À ce stade, je voulais vraiment abandonner array-init, et j'étais mitigé sur default-init (qui est facile à spécifier et à implémenter, mais que je considère comme essentiellement inutile). La réaction du LWG a été qu'il ne voulait que les formes les plus simples - pas de array-init ni même de default-init. J'ai été très heureux d'entendre cela, et j'ai pu écrire le langage standard nécessaire lors de la réunion elle-même (à environ 4 heures du matin). C'est donc de là qu'est venu le N3656. Le LWG y a jeté un nouveau coup d'œil, et avec une modification mineure (changer le type de retour de make_unique<T[N]> de void à unspecified, ce que j'ai fait avant que ce ne soit "gravé dans le marbre"), il était prêt à le présenter à l'ensemble du comité.
Ensuite, comme vous l'avez vu dans le procès-verbal, la préoccupation était que nous allions peut-être trop vite avec make_unique. N3588 était dans le mailing de pré-réunion à temps, mais c'était la première fois qu'elle apparaissait - presque toutes les propositions prennent plus d'une réunion pour passer de la première apparition à la motion formelle (ma première proposition, les foncteurs d'opérateurs transparents, était une exception encore plus inhabituelle puisqu'elle est apparue et a été votée sans changement à Portland). Il s'agissait d'une préoccupation tout à fait valable, soit dit en passant. En fin de compte, le vote a été adopté - les membres n'ont pas à expliquer leur vote, mais j'ai eu l'impression qu'il s'agissait d'une combinaison de facteurs : la proposition était très petite, personne n'avait d'objection sur le contenu réel et une implémentation était disponible.
Maintenant, je vais devoir réfléchir à nouveau à tout cela pour make_shared !
