À propos de WG21, Kona 2015

Quelques raccourcis :

Disclaimer

I wrote what follows mostly to keep my students informed of what a WG21 meeting is like, and I do not want to break the ISO code of ethics, but I do name people when I don't think it has any harmful effect (when discussions are more heated, I try to refrain from identifying individuals). Should you think it would be appropriate for me to remove things from this page, please tell me and I will proceed switfly.

Grâce à l'Université de Sherbrooke (en particulier, grâce à Jean Goulet et à Claude Cardinal du CeFTI) et au Collège Lionel-Groulx (en particulier grâce à Lucia Lepage), j'ai eu le privilège de participer à WG21, le comité de standardisation ISO du langage C++, qui est mon principal outil de travail et d'expression (outre la langue française elle-même). Il s'agit d'un truc prestigieux pour les informaticien(ne)s comme moi, et j'ai l'honneur de faire partie de ce comité depuis la fin de 2014.

Merci spécial à Joan-Sébastien Morales qui m'a prêté son chargeur d'ordinateur portable pour le voyage, le mien étant décédé... et atypique à un point tel qu'aucun commerce dans un rayon de 30 Km ne semblait tenir en inventaire des pièces de remplacement. Merci aussi aux autres collègues qui m'ont fait une offre semblable. C'est beaucoup grâce à vous que j'aurai pu travailler normalement cette semaine.

Ce qui suit est une sorte de journal de voyage, avec éléments humains et éléments techniques. Ce ne sera probablement pas volumineux, car je serai là en tant que participant plus qu'en tant que « spectateur intéressé », mais j'essaierai de vous donner une idée de l'expérience.

Qu'est-ce que WG21?

Comme c'est souvent le cas dans les milieux scientifiques, le nom WG21 est peu spectaculaire. On parle ici du Working Group 21, soit le comité de standardisation du langage C++. Pour les informaticien(ne)s, c'est probablement ici que l'explication se suffit à elle-même, étant donné qu'on tombe directement dans leur créneau.

Pour la majorité d'entre vous, par contre, ça reste obscur, alors j'essaie une explication (il se peut que ça ne vous rejoigne pas, mais c'est de bon coeur) :

Le langage C++ existe depuis les années '80. Il a été standardisé par l'organisme ISO en 1998, puis solidifié en 2003 avec des ajustements (relativement mineurs) jugés nécessaires de par l'expérience concrète obtenue depuis C++ 98. Une révision très majeure du langage a été ratifiée en 2011, et C++ 11 est l'essentiel du langage par lequel nous exprimons nos idées aujourd'hui. Une révision mineure (mais fort appréciée) a été ratifiée relativement récemment (C++ 14), et la prochaine mise à jour majeure, C++ 17, est celle sur laquelle nous travaillerons à WG21 pour les prochaines années. Les objectifs de C++ 17 sont très ambitieux, et font saliver les gens qui, comme moi, cherchent à tirer le maximum de ce que ce langage a à offrir.

On me dit que nous sommes ≈300 membres de WG21 sur la planète, et qu'environ cent personnes se présentent aux rencontres du comité (les autres font surtout des contributions par écrit). Pour la rencontre documentée ici, nous serons cinq délégués canadiens (Michael Wong, Botond Ballo, Hubert Tong, JF Bastien et moi-même)

Pour un peu de bagage supplémentaire sur l'événement, voir :

Pour les journaux de voyage d'autres participants, voir :

Début du contenu technique

Je vais mettre le contenu technique dans des blocs les mettant comme celui-ci. Si vous ça ne tombe pas dans vos cordes, passez par-dessus.

Sur le plan de la procédure, certains débats étant chauds et les gens qui débattent étant mes pairs, je vais m'abstenir de donner dans le nominatif dans ces sections (à moins que ça n'ait pas d'incidence).

Fin du contenu technique

Jour -1 17 octobre 2015

Reflet de ce que j'ai vécu à CppCon 2015 il y a quelques semaines, « l'expérience Kona », si on peut la nommer ainsi, sera nettement différente pour moi de ce que j'ai vécu à Lenexa plus tôt cette année. Pour plusieurs raisons :

Avec un peu plus de 130 textes à lire (n'ayant pas pu le faire avant) et une longue liste de défectuosités (Defects) et de problèmes (Issues) rapportés au comité, en particulier à Core (là où j'étais impliqué à Lenexa, et où je compte m'impliquer cette fois aussi), j'espérais avoir le temps de me préparer convenablement aujourd'hui. La vie ne m'a pas permis de faire cela, évidemment, mais je suis parvenu à lire une vingtaine de documents et à préparer mon sac de voyage.

La météo prévue à Hawaii cette semaine indique des températures aux alentours de 28° C toute la semaine. La créature de temps froid que je suis risque d'être grognon...

Jour 0 18 octobre 2015

Ce fut facile de se lever ce matin (l'adrénaline, je présume) mais j'écris ceci vers 6h30 à l'aéroport et je m'endors. Ce sera une longue journée.

En attendant en file pour me prendre un café, j'ai bavardé avec une dame et ses deux garçons. Je lui ai demandé où elle allait, et elle m'a expliqué qu'elle retournait à Memphis où elle vit depuis six ans et où ses deux garçons sont nés. Elle m'a dit venir de Mirabel, et quand je lui ai fait remarquer qu'elle n'avait pas d'accent et que ses garçons parlent un excellent français (on n'aurait pu savoir qu'ils sont américains sur la base de l'accent), elle m'a expliqué que la richesse de parler deux langues et l'importance de parler français, quand bien même ce ne serait que pour bavarder avec les grands parents.

Voyage sympathique de Montréal à Dallas. Les voisins de mon siège ressemblent à des amis de mon papa et de sa dulcinée, Réal et Jacqueline. J'ai apporté sur mon iPod un épisode de La soirée est encore jeune (certainement ce que je préfère à la radio!) et deux épisodes de CppCast (un avec Anthony Williams à propos du parallélisme et de la concurrence, et un autre avec Kate Gregory portant sur l'enseignement de la programmation).

L'aéroport de Dallas est plutôt grand, et on voyage d'un terminal à l'autre par train aérien (il y a cinq terminaux si j'ai bien vu). J'ai pu prendre un café et bavarder un peu avec mon amoureuse Za et quelques-uns de mes enfants (vive Skype des fois!). Le reste de la pause entre vols a été consacré à la préparation en vue de la semaine qui s'en vient (j'ai vraiment pas fini).

Entre Dallas et Los Angeles, j'ai encore écouté des épisodes de CppCast (un avec JF Bastien qui discute de WebAssembly, un avec Sean Parent qui vaut toujours la peine d'être entendu, et un autre avec James McNellis portant sur le CRT universel entre autres choses). Une hôtesse de l'air, très gentille par ailleurs, a perdu pied quand l'avion a été bousculé et m'a renversé quelques cubes de glace dans le dos, mais c'était plutôt cocasse, pas fâchant.

L'aéroport de Los Angeles est beaucoup moins propre que celui de Dallas, c'est assez frappant. Je présume qu'il est très grand, mais (a) je ne voyais pas du hublot alors je n'ai pas eu de coup d'oeil sur les lieux, et (b) la porte de laquelle je partirai est dans le même corridor que celle d'où je suis débarqué alors j'ai une perspective extrêmement limitée sur les lieux. Ce fut difficile de trouver une prise de courant pour travailler, et le service de WiFi gratuit est très mauvais (ça ressemble à une excuse pour pousser les gens à payer un extra pour avoir un service potable). Les gens sont sympathiques par contre.

Quelques courriels de mes chics étudiant(e)s et de quelques ex-étudiant(e)s; je suis toujours content d'avoir de leurs nouvelles.

Pour le dernier (long!) trajet, de Los Angeles à Kona, je n'étais pas le seul membre de WG21 dans l'avion, loin de là. Hubert Tong était dans le coin, Jonathan Wakely et Botond Ballo étaient près de moi dans l'avion, j'ai croisé David Sankel, Thomas Köppe et plusieurs autres. On a un peu bavardé sur la route, et j'ai convenu de séparer les frais de taxi avec Jonathan et Botond à l'arrivée.

Mon voisin de siège était un prof d'une université texane qui s'en allait dans un colloque sur le e-Learning. Sympathique personnage, il m'a un peu expliqué ses travaux, mais disons que le rythme de sa conférence était tout autre que celui de la mienne (il pensait aller à la plage une fois sa présentation faite; disons que c'est pas le profil de mon groupe).

Le trajet est essentiellement en ligne droite au-dessus du Pacifique, et dure cinq heures et demie. On passe le seuil de l'équateur (Hawaii est juste au Sud de cette « ligne ») en cours de route. Je me suis permis de manger un peu dans l'avion (un wrap au poulet; je commençais à avoir faim). J'ai essayé de manger un peu de fruits à l'aéroport de Los Angeles mais c'était 12 USD pour un petit casseau de melon alors j'ai pris un just de frutis Minute Maid à la place (trois dollars et demie, c'est cher mais moins pire).

Hawaii est un archipel de quelques îles, et Kona est la plus grande (Honolulu, qui est connu, est pas mal plus petit). Sur l'île de Kona même, on trouve deux montagnes de plus de 4 Km de haut chacune. On ne les voit pas ce soir, dans l'obscurité.

Truc amusant : la lune est différente. Tous ceux qui, comme moi, viennent de l'Est ont remarqué que la forme du croissant est inhabituelle. Je ne m'attendais pas à ça.

L'aéroport de Kona est une expérience : tout est ouvert. Il n'y a pas de « bâtiments » fermés à proprement dit. Les enfants voulaient que je prenne une photo mais il faisait noir on avait beaucoup à faire. On a eu des ennuis à l'aéroport parce que les bagages d'un collègue ne nous avaient pas suivis (les gens que la compagnie d'aviation pensent que c'est parce que son transit à Los Angeles était bref et que les bagages ne se sont pas rendus à temps); il semble que le pauvre ami devrait les recevoir demain en fin de journée.

Thomas Köppe a loué une voiture et nous a amenés, Jonathan Wakely, Botond Ballo et moi, à l'hôtel. Thomas et un très chic type. Thomas et Jonathan ont dû loger à dix minutes de marche de nbous pour les premiers jours de la rencontre, car il y avait un Iron Man ici la semaine dernière et que certains touristes ont choisi de rester plus longtemps. L'hôtel en soi n'a pas vraiment « d'intérieur ». Les portes donnent directement sur l'extérieur, l'accueil est à l'extérieur... Idem pour l'aéroport: il n'y a pas de «dedans». C'est particulier. Ma chambre est fermée et a un toit, cela dit.

Pour le reste, il fait noir alors difficile de dire bien des choses sur l'environnement dans la ville de Kona. C'est une petite ville ici, mais avec de gros hôtels. Je pense qu'on est près de la mer mais dans l'obscurité, c'est difficile à dire. Je me suis couché vers minuit heure d'Hawaii, six heures du matin heure de Montréal.

Jour 1 19 octobre 2015

Je me suis levé plus tard que prévu (alarme pour 5h30, mais réveil à 6h, ce qui me serre un peu dans le temps). C'était ma faute, mais pas entièrement : j'ai bien mis l'alarme à 5h30 mais l'heure du réveil était « à l'envers » (PM au lieu d'AM). Ça devrait être un problème réglé pour demain.

Les produits d'hygiène (savon, shampooing et autres) sont faits à Hawaii et sont tous à base de noix de coco.

Pensée pour ma chumette Hélène Normandeau, qui m'a souvent parlé de son voyage ici avec sa grande fille, et qui en a gardé de bons souvenirs. Ma chambre donne bel et bien sur le Pacifique (le balcon donne presque directement sur la mer, et je suis au niveau du sol; difficile de demander mieux).

Petite jasette avec mon amoureuse Za, puis je me mets en marche...


Un des problèmes de je vais avoir cette semaine est organisationnel : je dois présenter les travaux d'autres personnes devant certaines instances, et je veux bien le faire, mais je ne suis pas encore maître des canaux de communicaton ici (il y a plusieurs Wiki, des canaux IRC pour la communication directe, il se passe des choses à plusieurs endroits en même temps, etc.) et certains d'entre eux ne me sont pas familiers. Une partie de ce que je dois faire cette semaine est trouver moyen de m'organiser pour être aux bons endroits, aux bon moment.

Il y a plus de 130 propositions à débattre, en plus de nombreux rapports de défectuosité à traiter. Il faut comprendre qu'ici, on traite à la fois d'idées mises sur la table pour améliorer le langage (nouvelles idées, nouveaux mots, nouvelles structures grammaticales, glissements sémantiques pour des formules existantes, retrait de mots et de structures grammaticales désuètes ou inadéquates, nouveaux outils, etc.) et de défectuosités remarquées par nous-mêmes ou par des gens qui utilisent le langage pour s'exprimer (énoncés sujets à interprétation, cas pathologiques qui nous ont échappé, effets a priori insoupçonnés de possibilités langagières qui semblaient anodines, etc.). On catégorise ces divers dcouments en groupes de travail et on fait ce qu'on peut dans le temps qu'on a pour améliorer la situation. Une semaine ne suffit pas, évidemment, mais c'est épuisant et bénévole, alors on ne peut pas vraiment faire plus.

Truc qui nous aidera cette fois : les débats auront lieu à l'hôtel même où nous résidons, alors on va épargner les délais de transport qui nous coûtaient une heure par jour à Lenexa (c'était correct, mais on sera plus efficaces en gagnant cette heure chaque jour).

Je prends un peu de temps pour réviser les intentions des gens dont je vais soutenir les propositions ici, et je me mets en marche (pas assez de temps pour faire mieux).


Même la rencontre se passe à l'extérieur; il faiut chaud mais il y a un petit vent (nous sommes juste à côté de l'océan) alors c'est pas si mal pour le moment. Je suis probablement le 80e ou 100e à arriver dans la salle (je n'aurai pas le temps de déjeuner). L'ambiance est plaisante et il y a du café. Heureusement pour moi, il y a aussi une prise de courant pas loin. Je suis installé non-loin de nos hôtes, et il se trouve que mon voisin immédiat est Billy Baker, le chic type du monde de l'aviation avec lequel j'ai bavardé à CppCon 2015.

Je l'ai déjà écrit : la plus grosse différence entre les rencontres précédentes et celles comme CppCon 2015 et la présente est que je connais les gens, alors c'est beaucoup plus agréable (et occupé!) maintenant.


Clark Nelson nous accueille et présente l'agenda, Herb Sutter est prend des notes (et le guide à l'occasion). Thomas Plum nous acceuille en tant qu'hôte. Il nous informe que nous sommes dans la « salle de bal » car nous sommes trop nombreux, mais que nous ne devrions pas être ici trop souvent (l'essentiel des travaux se fait en sous-groupes). Les séances de travail de soirée se feront ici, par contre. Il y a un peu de confusion autour des codes d'accès au WiFi; j'au eu le mien hier soir, j'espère qu'il restera valide car il est sympathique mais chaque code n'est utilisable que par trois postes concurremment.

Il y a une douzaine de nouveaux participants à WG21 ici. Clark Nelson explique très sommairement les règles. Une fuille passe et je vois que j'y suis indiqué « Participating non-member » alors il y a un irritant technique; j'informe Stephen Mitchell et Michael Wong pour voir si on peut arranger ça. Alex Rosenberg de Sony, que j'ai rencontré à CppCon 2015, est avec nous ce qui est bien.

On fait un « tour de salle ». On doit être autour de 120-140 personnes. Il y a des représentants de plusieurs pays (une dizaine, incluant la Slovénie, mais sans droit de vote), le reste est des entreprises.

Clark Nelson présente l'ordre du jour, qui ne couvre pas les sessions de soirée. On passe en revue les minutes des rencontres précédentes et les documents les plus à jour de certaines spécifications techniques, mais il n'y a pas de gros problèmes (on les a tous lus). Il y a de petits irritants ici et là, sans plus. On est passés d'un schème de numérotation à un autre et ça cause un peu de confusion dans le cas du document sur les concepts, à savoir lequel est le plus récent (le plus « officiel »).

On fait le tour des plans de match pour les divers groupes de travail. Pour CWG et EWG, c'est de la routine (ha ha!), au sens où on passera en revue les candidats les plus probables pour C++ 17. Pour LWG, de gros documents pour ASIO et les intervalles teinteront les travaux. Pour LEWG, il y a trop de documents sur la table pour le temps disponible alors ce sera une question de prioriser les tâches.

Herb Sutter prend la parole pour expliquer la mécanique menant à C++ 17. On veut que le document sorte en Finlande vers juin 2016 sous une forme « Feature Complete » (avec retouches mineures à faire, sans plus), donc il reste trois rencontres incluant celle de cette semaine. On espère fusionner des spécifications techniques dans le tronc principal de C++ 17 (les TS de concurrence et de parallélisme semblent prometteurs). On doit voir si les concepts et les intervalles, deux composants géants, pourraient faire partie de cette liste, et travailler pour qu'ils y soient le cas échéant.

Ville Voulitainen demande une indication en session plénière pour savoir l'avis de la salle. Pour les concepts, c'est partagé (un peu plus de non que de oui, mais beaucoup d'abstentions). Herb Sutter demande si le fait que les concepts ne soient pas encore mis en application dans la bibliothèque standard est l'obstacle, alors qu'on pourrait les utiliser dans les bibliothèques naissant des spécifications techniques; ceci reçoit un assentiment plus important. Quelqu'un demande si on pourrait rendre ce support optionnel; Herb Sutter dit qu'on va en discuter dans EWG.

On examine qui travaillera dans chaque groupe. Pour CWG, on sera une quinzaine. Pour LWG, on parle d'une quinzaine aussi. Pour LEWG, on parle d'une vingtaine. Pour EWG, on parle d'environ trente. Pour SG1 Concurrency, une vingtaine. Pour SG6, qui tiendra deux jours de travail, une douzaine. Pour SG12 Undefined Behavior, qui aura besoin d'une journée, on parle de huit personnes. Pour SG7 réflexivité, il n'y aura pas de rencontres. On fait le tour des noms des pièces mais je ne comprends pas assez bien les noms pour les prendre en note. On est répartis dans trois bâtiments.

On discute un peu à propos des séances de travail en soirée. Des séances de travail informelles s'ajouteront, en particulier sur la question des contrats. Les séances débuteront à 19h30 pour que les gens puissent manger. Mercredi soir, en particulier, on discutera de ce qui a trait à SG14 avec Michael Wong. Jeudi soir, ce sera les modules avec Gabriel Dos Reis. Mardi soir, ce sera les Feature Testing Macros avec Clark Nelson. Howard Hinnant propose de tenir une séance sur std::date vendredi, mais vendredi la plénière se terminera à 18h alors il se peut que la séance de soirée commence un peu plus tard. J'ai manqué le sujet de celle de ce soir, mais à 17h il y aura un bref retour sur les travaux de la C++ Standard Foundation.

On gère l'équipement du mieux qu'on peut (projecteurs, prises de courant, écrans, etc.). Jens Maurer est le maître d'oeuvre. Puis, on y va... Il est 9h25. Les pauses cette semaine incluent café et eau, puis on s'arrange avec nos troubles.

J'ai pris quelques minutes pour discuter avec Michael Wong et saluer Alex Rosenberg. Je veux savoir quand je devrai me déplacer pour défendre les documents des gens que je représente ici. Pour le texte de Karl-Étienme Perron, ce sera vendredi matin devant EWG. Pour le texte de Sean Middleditch, le moment exact n'est pas clair encore.


Notre pièce est climatisée, et sa taille convient au groupe que nous sommes (c'est serré mais ça entre; à Lenexa, on était coincés dans une pièce un peu trop petite). On fait un peu de logistique, puis on commence.

Mike Miller présente le plan de match. On commencera par des trucs « légers » car il nous manque des joueurs, en particulier Jens Maurer qui est très important pour ce groupe, qui présentent des trucs devant d'autres comités. Certains groupes ont beaucoup de documents à traiter en amont, mais de notre côté, nous recevons beaucoup de travail des autres groupes de travail, pour formaliser la terminologie, alors l'agenda est plein mais l'ordre dans lequel les travaux seront faits reste indéfini en partie.

Core Issue 2001: non-directive is underspecified

Le standard existant parle, pour le préprocesseur, de « non-directives ». Dinka Ranns préconise « conditionally-supported directive » pour rendre le comportement et le support dépendant de l'implémentation. Ok.

Core Issue 2099: Inferring the bound of an array static data member

Précision pour les cas où la taille d'un tableau est déterminée par le compilateur. Ça ne pose pas de gros problème. En gros, on permet formellement les deux syntaxes suivantes :

struct X {
    static int vals_0[] = { 2,3,4,,7,11 };
    static int vals_1[] { 2,3,4,,7,11 };
 };

Ok.

Alisdair Meredith se joint à nous pour quelques-unes de ses propositions.

Remove Deprecated Use of the register Keyword

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0001r0.html

En gros, on garde le mot qui est utile, mais on supprime son sens traditionnel, qui est déjà déprécié. Il y a un précédent, le mot clé export, qui a subi le même sort avec C++ 11. Hubert Tong demande si on a déjà une note quant à la compatibilité avec C dans le standard; il faut aussi examiner la compatibilité entre C++ 14 et C++ 17. On réarrange quelques détails mineurs. L'air de rien, c'est un changement mineur en apparence, mais qui a beaucoup d'impacts pour les programmes C++ qui compilent des fichiers C utilisant encore ce mot-clé (faudra utiliser des macros ou faire un peu de ménage dans les sources; Alisdair Meredith fait remarquer qu'il est illégal de changer le sens d'un mot clé par une macro, alors faudra faire attention).

Remove Deprecated operator++(bool)

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0002r0.html

Hubert Tong fait remarquer que -- et ++ sur des bool ont été standardisés pour C avec... C11. Ces opérateurs « flippent » la valeur du booléen. Faudra donc insérer une section sur les incompatibilités avec C. On rit un peu; c'est fou des fois les surprises que deux groupes de travail peuvent se causer mutuellement. Hubert Tong fait remarquer que pour atomic<bool>, seul g++ implémente correctement ++ et --. Alisdair Meredith va vérifier les éléments manquants pour la compatibilité C et nous revenir.

D0012R1: Make exception specifications be part of the type system, version 5

Hubert Tong demande si la suggestion de Richard Smith portant sur les conversions de pointeurs de fonctions avec ou sans qualifications cv est tenue pour compte ici. Jens Maurer dit que oui.

Jens Maurer rappelle qu'à Lenexa, la version précédente de ce document a surpris des gens qui ne pensaient pas devoir voter sur le sujet. Une nouvelle version a circulé, des discussions ont suivi. Il y a plusieurs changements intéressants, dont une nouvelle section sur les impacts que ce changement entraînera sur la bibliothèque standard. Ces changements impacteront éventuellement aussi le texte sur la mémoire transactionnelle et les qualifications en ce sens. On pourrait vouloir fusionner ces règles dans une même section, clause 4 (cv, transaction_safe* et noexcept), mais la proposition sur la table n'est pas encore là.

Étant donné qu'on parle de formulation pour les conversions de pointeurs de fonctions qualifiés, il y a plusieurs subtilités (peut-on enlever noexcept et ajouter const à travers une même conversion, par exemple? Si plusieurs conversions interviennent, y a-t-il un ordre à respecter?). Dinka Ranns fait remarquer qu'un pointeur de fonction noexcept est une nouvelle créature, et que le standard comprend une multitude de pointeurs de fonctions; il faudra être prudents sur les impacts ailleurs dans le texte de cet ajout. Le sens même du terme pointeur de fonction avec ou sans guillemets est subtil (inclut-il les cas noexcept ou ne les inclut-il pas?). Dawn Perchik dit préférer être verbeuse à être ambiguë. C'est pas facile de trouver une tournure de phrase claire et pas trop verbeuse pour un changement qui a autant d'impact sur un texte de 1600+ pages.

Hubert Tong faire remarquer quelques incohérences d'ordonnancement de clauses normatives à l'intérieur de certaines clauses. On trouve un ajustement pas trop complexe à appliquer. On fait plusieurs remarques et retouches mineures. Par exemple, « T0 is identical to T1 » est utilisé, mais alors que le standard définit « T0 is the same type as T1 », le terme « ...is identical to... » ne semble pas défini. C'est une question complexe; on suggère de soumettre la question à l'éditeur, et on regardera la terminologie une fois qu'une définition aura été ajoutée, le cas échéant; pour le moment, on va considérer les deux comme étant équivalents. On fait pas mal le tour, et ça va retourner devant EWG.

Core Issue 1895: Deleted conversions in conditional operator operands

Un vieux problème de conversion de champs de bits avec l'opérateur ternaire (quel est le type de l'expression?). On a raffermi le texte en général, et c'est plus léger (parfois, quelques définitions de plus allègent un texte autrement plus complexe). Aaron Ballman trouve moyen de clarifier la question de « ...is identical to... » au passage. On a un concept de « the ambiguous conversion sequence » ici qui allège l'écriture, un peu comme « the null pointer » le fait.

On prend une pause dîner à 11h30, parce que la journée à commencé tôt. Je parle brièvement à mes adorables chiboukis par Skype (Jens Maurer, qui a un enfant de trois ans et, ma foi, parle un français de grande qualité, s'amuse de mon adorable Ludo qui maltraite la caméra) et on accroche un sandwich au Subway's du coin avant de reprendre le boulot. Il fait très chaud à l'extérieur mais pour se rendre au resto, faut marcher l'équivalent d'un coin de rue sur le bord de la mer. Je me fais un peu éclabousser, ce qui est plutôt agréable. Ça et l'odeur de la mer, évidemment 

Pour celles et ceux qui se demandent (comme Za me l'a souligné) pourquoi je prends du commercial alors que je suis à Hawaii, sachez que :

J'ai pas eu le temps de déjeuner ce matin, et le déjeuner de l'hôtel est un buffet à... 20 USD. Alors c'est non  Jonathan Caves a trouvé un endroit pas loin où il y avait un choix de bière raisonnable alors peut-être tantôt.

Mon beau-père, le chic Jocelyn Desfossés, m'a demandé de prendre un drink local à sa santé. Je ferai sans doute ça lors d'une séance de travail en soirée dans le courant de la semaine. Le jour, ça va pas mal être du café.

On reprend à 13h. Mon accès au WiFi pose problème; je ne sais pas ce que ça va donner cet après-midi.

Mike Miller mentionne que lui et Jens Maurer ont retravaillé un peu une formulation sur les conversions ambiguës, à savoir si la conversion de T0 à T1 est ambiguë mais la conversion de T1 à T0 ne l'est pas : déclare-t-on expr?declval<T0>():declval<T1>() ambigu ou non? L'exemple de Mike Miller est :

struct B;
struct A { A(const B&); } a;
struct B { B(const A&); operator A() const; } b;
// ...
x ? a : b;

On examine le tout. Hubert Tong mentionne que pour une conversion enfant vers parent avec des valeurs, pas des copies, on pourrait vouloir (ou non) le Slicing, mais n'est pas certain de son exemple. Richard Smith parle du côté surprenant de l'ajout d'une nouvelle approche de conversion qui rendrait l'expression ambiguë. On va y réfléchir un peu.

Rewording inheriting constructors (core issue 1941 et al)

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0136r0.html

Richard Smith mentionne que le texte existant posait problème à certains égards, menant à l'ajout de fonctions chez l'enfant. Il préconise de traiter les constructeurs hérités plus comme des directives using. Je fais remarquer que les constructeurs hérités ne masquent pas le constructeur par défaut des enfants, dans un cas comme :

struct B { B(int); };
struct D { using B::B; };
int main()
{
   D d; // Ok, car D::D() n'est pas supprimé
}

... mais Richard Smith indique que c'est par design. Ça me semble un peu surprenant, mais je comprends l'idée. On demande si on devrait ajouter une section pour ce qui a trait à la compatibilité avec les versions antérieures du standard; cependant, on parle d'une particularité de C++ 11 qui ne fonctionnait pas vraiment en pratique alors c'est pas clair. John Spicer est d'avis que c'est préférable, alors on va procéder. Richard Smith va retoucher la formulation et nous revenir.

Jens Maurer revient d'EWG, où la vaste majorité des gens ont appuyé ou appuyé fortement sa proposition d'intégrer les spécifications d'exceptions au système de types du langage.

Core Issue 1776: Replacement of class objects containing reference members

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0137r0.html

L'idée est de déterminer le sens à donner à un objet remplacé par Placement New qui contiendrait un attribut qui soit une référence. On commence par clarifier la définition du mot « objet », au sens d'un lieu d'entreposage avec une durée de vie (en C, mais en C++ c'est un peu plus subtil). L'adresse d'un objet est l'adresse de son premier byte. Le début et la fin de la vie d'un objet contenu dans un union peut débuter par une affectation à l'un de ses membres; la possibilité de faire un reinterpret_cast de l'adresse d'un membre vers l'adresse du struct ou de l'union qui l'englobe mène à une validité pour laquelle il n'y a pas consensus dans la salle.

Hubert Tong soulève la question de la compatibilité avec C, surtout pour les tableaux bruts, les struct et les union. La proposition l'interdisait, mais on décide de mettre les freins sur ce point. John Spicer demande quel est l'intérêt de dire que deux trucs sont à la même place mais qu'on ne peut en profiter. Hubert Tong fait remarquer que bien qu'il ait souhaité précédemment que l'adresse d'un tableau soit la même que l'adresse de son premier élément, il préfère reculer sur ce point (le comportement de sizeof() pourrait surprendre).

On se questionne sur le risque de changer l'élément initialisé d'un union en prenant l'adresse d'un autre membre, mais Richard Smith pense que cela ne peut se faire que par une affectation. On bavarde sur le memcpy() d'un objet dans un autre objet de même taille mais de type différent; c'est indéfini mais ça marche dans essentiellement tous les cas. Jason Merrill fait remarquer que passer par memcpy() irrite bien des gens. Aaron Ballman rappelle tout ce qui est réseautique, et les risques que l'on brise Internet en faisant une bêtise ici. Jens Maurer parle de l'importance de ne pas empêcher l'optimiseur de faire son travail dû à des risques d'alias (il parle de ses travaux sur des char*, qui peuvent être des alias pour n'importe quoi, ce qui empêche l'optimiseur de faire son travail correctement; Richard Smith suggère qu'on ajoute un autre type qui ne soit pas assujetti à ce risque d'être un alias pour n'importe quoi; c'est un dossier trop gros pour traiter sans réfléchir). Jens Maurer parle aussi du cas du Placement New, qu'on ne veut pas bloquer. Hubert Tong parle du cas où on ferait un Placement New d'un élément d'un union à partir d'un autre élément du même union...Brrr... Richard Smith parle d'ajouter une barrière dans le code généré pour ce cas.

On parle du risque de :

union { int n; float f; } u;
void f(int*, float*);
void g()
{
   f(&u.n, &u.f);
}

... mais on convient qu'on ne pourra se protéger contre des horreurs comme ça.

On convient qu'on  ne veut pas briser la règle du Common Initial Subsequence que C et C++ partagent dans le cas d'une classe qui respecte le Standard Layout. On discute de la nuance entre convertir de tableau à pointeur sur sont premier élément (légal, implicite par décrépitude, possible par static_cast) et convertir de pointeur sur un tableau à pointeur sur un premier élément (requiert un reinterpret_cast). On parle ici de trucs profonds, à savoir si on peut par exemple prendre un pointeur, le convertir de force à une référence sur un tableau et adresser ses éléments (une décrépitude inversée; certains sont pour, d'autres sont contre).

Hubert Tong fait remarquer qu'un pointeur sur n'importe quel élément d'un tableau permet, si on connaît son indice, d'accéder le tableau entier suivant un reinterpret_cast convenablement fait. Selon lui, ça permet d'accéder le contexte englobant dans un struct de type Standard Layout. Richard Smith donne le point de vue d'un optimiser sur le sujet, c'est-à-dire qu'étant donné ceci :

enum char_t : char {};
struct X {
   char_t x[10];
   int n;
};
int f() {
   A a { ... };
   a.n = 5;
   g(a.x);
   return a.n;
}

... un optimiseur peut-il escamoter l'initialisation et a.n et simplement retourner 5? Si on permet la dé-décrépitude, on ne peut pas, car on pourrait retrouver le X par son premier élément a.x. Du point de vue de Hubert Tong, c'est de pouvoir passer d'un pointeur sur un élément d'un tableau à une référence sur un tableau qui pose problème; selon lui, la décrépitude automatique de C mène le code C à faire ce genre de manoeuvre pour avoir l'équivalent d'une référence sur un tableau. John Spicer est d'avis qu'il faut le permettre.

Selon nos implémenteurs de compilateurs, le statu quo actuel est de ne pas permettre la dé-décrépitude permise depuis C++ 14, qui a clarifié ce que signifie « pointer vers » quelque chose. On essaie de retracer le changement terminologique qui nous a amené ici. Si A a la même adresse que B et B a la même adresse que C, alors A a la même adresse que C (transitivité), mais cela ne signifie pas qu'on puisse convertir les pointeurs de l'un à l'autre. Hubert Tong trace une distinction dans le cas ci-dessus entre a.x et a.x[0], indiquant que a.x est le premier élément de a, pas a.x[0], même si &a.x et &a.x[0] mènent à la même adresse.

On a consensus sur le fait que dans un POD struct, l'adresse du struct est la même que l'adresse de son premier élément. La question de la convertibilité entre un pointeur sur un élément d'un tableau et référence sur le tableau en question demeure sujette à débats. On revient sur la proposition générale de Richard Smith qui est plus complexe que ça. On pense que ceci :

union { int n; double d; } u;
void f(int *p) { *p = 3; }
void g() { f(&u.n); }

... devrait démarrer la vie de u.n. Richard Smith pense que oui (comme ceci ou en passant pas un Placement New). On fait remarquer qu'on peut utiliser &u.n et &u.d de manière interchangeable en termes d'adresse, mais qu'on ne peut accéder qu'au pointé de l'élément actif.

On s'arrête quelques minutes, question de se refaire un cerveau, puis on poursuivra les débats sur cette question.

Mike Miller mentionne que les objets levés par des exceptions ne sont pas des temporaires, techniquement (leur durée de vie est différente), et peuvent être omis des cas qui discutent d'objets temporaires, mais faut considérer la levée d'exception comme un cas distinct pouvant créer un objet. Richard Smith demande quelle est la durée de vie d'un objet créé par une exception; on refuse de répondre.

Dinka Ranns fait remarquer que le texte utilise deux écritures distinctes pour parler de la fin d'un tableau de n éléments, soit « après le n-1 ième » et « là où se trouverait hypothétique élément n ». Faudrait unifier. On penche vers un hypothétique élément n. Richard Smith suggère une autre formulation qui couvrirait les deux cas.

On débat de ce qui démarre la vie d'un élément d'un union. C'est une question étonnamment complexe quand on considère qu'un union peut, directement ou non, en contenir d'autres.

On a des formules pour couvrir des cas où deux membres d'un même union ont une Common Initial Sequence, et où on accède à un membre actif en passant indirectement par un membre inactif. C'est complexe et on va ajouter un exemple.

Dans bien des cas, ce qu'on formule au fond est :

Par contre, ceci est correct :

struct T1 { int a, b; };
struct T2 { int c; double d; };
union U { T1 t1; T2 t2; };
int f() {
   U u = { { 1, 2 } }; // t1 est le membre actif
   return u.t2.c;      // OK, comme si on passait par u.t1.a dû à la sous-séquence initiale commune
}

... correct au sens normatif, du moins (on ne parle pas d'esthétique ici  ).

Il y a une petite nuance entre initialized member et active member pour un union, du fait qu'une initialisation par défaut peut être faite pour le premier attribut d'instance d'un union dans certaines circonstances sans que l'on ne lui ait affecté une valeur. Dans ce cas, initialisé implique actif, mais sur le plan terminologique il n'y a pas eu d'activation à proprement dit (pas d'affectation, pas de Placement New).

On discute, dans le cas où des objets intermédiaires doivent être générés, si on devrait parler de vacuous initialization ou de default initialization (on parle d'un union qui contient un union ici, et où l'initialisation d'un membre interne force la création de la chaîne de membres qui y mènent). Richard Smith dit souhaiter qu'on ne fasse pas d'initialisation du tout, ce qui pourrait simplifier bien des choses (on parle tout de même de compatibilité avec C dans bien des cas ici).

On revient sur Core Issue 1895

Il reste un peu de travail terminologique à faire ici, pour ce qui touche aux séquences de conversion ambiguës. On a de la difficulté avec le réseau à un point tel qu'on arrête cinq minutes avant la fin pour souper. Tout le monde est perplexe, on ne finit jamais d'avance; quelqu'un lâche un « slackers » (paresseux!)  . On reprendra là demain pour les travaux de CWG.

Petite pause pour manger une croûte, puis on attaque la session de travail de la soirée. Je regarde le site de Radio-Canada pour constater l'état des élections. Pas fâché d'un changement de gouvernement, c'est le moins qu'on puisse dire, mais j'aurais préféré un gouvernement minoritaire et ça ne semble pas être ce qui s'annonce... Alisdair Meredith passe bavarder; ses quelques propositions d'aujourd'hui (mettre register, throw(X,Y,Z) et quelques trucs dépréciés de la bibliothèque standard officiellement à la retraite) semblent toutes acceptées. Ça va alléger le standard.


Après avoir parlé un peu avec ma belle Za (il est tard à la maison, presque minuit, alors qu'ici ce n'est que l'heure du souper), je suis allé me chercher une assiette de Thaï dans un petit resto pas loin (pas vilain, pas transcendant) et j'ai essayé de prendre des photos du paysage pour ma petite famille (les photos, c'est pas vraiment moi, mais j'essaie d'être gentil).

En mangeant le tout, j'ai constaté les résultats de l'élection, puis en regardant mes liens « matinaux » (blogues, comix, trucs techniques), je me suis fait bloquer par le fournisseur Internet local et on m'a indiqué que j'avais un comportement criminel. En regardant les causes possibles de cette accusation, je suis resté perplexe, alors j'ai contacté les dames à l'accueil qui ne savaient manifestement pas ce dont je parlais. Elles m'ont redirigé vers le fournisseur qui m'a indiqué... que j'avais trop d'onglets ouverts. Ils pensaient que je cherchais à opérer un système de piraterie Internet ou un truc du genre. On a réglé le tout et je suis retourné à mes lectures.


Je suis arrivé quelques minutes avant la séance de soirée sur le type variant, un sujet très, très chaud sur Internet depuis Lenexa. Je n'étais pas le premier, et ça devrait brasser ce soir. Par écrit, les débats des derniers mois ont souvent débordé de ce qui est civilisé. On verra bien.

Quelques échanges avec Hubert Tong (qui vit une situation hôtelière horrible, ayant pris un hôtel à plus de 45 minutes de route de celui où nous travaillons), Billy Baker et Michael Wong à propos de ce qui s'est passé dans les autres groupes. Les exécuteurs semblent un peu bloqués (plusieurs propositions de qualité, mais qui ne convergent pas, et c'est un irritant puisque le problème à résoudre est multifacettes), les coroutines vivent aussi une situation de propositions de qualité concurrentes mais semble que celle de Gor Nishanov ssoit proche d'être acceptée; les conversions entre types primitifs et chaînes de caractères de Jens Maurer progressent bien...

Le sujet de la soirée est variant. L'idée de base est que nous voulons un type volabulaire standard qui puisse remplacer les union étiquetés. Par exemple, au lieu de :

struct X
{
   enum { ENTIER, REEL, CHAR } code;
   union
   {
      int n;
      double d;
      char c;
   };
};
X x;

... nous voulons permettre cela :

using X = variant<int, double, char>;
X x;

..,. puis nous voulons permettre, selon les acceptions, un accès positionnel (p. ex. : x.get<0>() pour accéder à l'entier), un accès par type (p. ex. : x.get<int>() dans le cas où le type est unique dans un variant donné), un visiteur à partir de fonctions sur la base du type (sorte de sélective par type), etc. Le problème est qu'il y a des points litigieux :

Ville Voulitainen met la table. Axel Naumann fait une mise en situation et présente les problèmes clés (en gros, ceux susmentionnés). Axel Naumann pose la question en ces termes : quel est le prix que nous acceptons de payer? Toutes les solutions possibles ont au moins un défaut, et il faut trouver la meilleure / la moins pire option pour le standard.

La bonne nouvelle est que nous sommes nombreux ici ce soir (environ cinquante personnes pour la séance de soirée).

Nathan Myers demande des explications pour la question du coût en espace si on demande un type qui offre de plus fortes garanties face aux exceptions. Axel Naumann précise.

Jonathan Wakely, qui prend des notes, demande avec fermeté que l'on évite la répétition des arguments lancés des milliers de fois lors des discussions électioniques. Bjarne Stroustrup demande la patience et le respect, car plusieurs personnes sur place peuvent ne pas avoir suivi les (longs et lourds) débats électroniques. Axel Naumann suggère aux aficionados des diverses options d'exprimer leur point de vue.

Gabriel Dos Reis dit ne pas avoir écrit de propositions car il avait l'impression que sa préférence ne rencontrait pas l'assentiment populaire. Il sedit d'avis que bien programmer ne devrait pas être un concours de popularité.

David Sankel se présente sur la scène avec son laptop. Il présente sa vision comme Simply Variant car l'interface publique en est très simple. Il vise à ne pas pessimiser le comportement du type. Selon lui :

Selon lui, offrir plus que la garantie de base lors d'exceptions forcerait le code client d'un variant à altérer sa propre interface et à simuler de manière externe le double-buffering. Il compare avec le cas d'un std::vector, pour lequel les enjeux sont essentiellement les mêmes.

Il amène aussi Simply Strong Variant sur la table. Les garanties sont plus fortes face à des exceptions, mais l'interface est un peu pessimisée et on accepte le double-buffering. Il dit que dans ces cas, faudrait que les gens qui veulent que ça aille vite reviennent aux union étiquetés. Axel Naumann mentionne qu'il y a beaucoup de types qui ne sont pas marqués noexcept et qui ne lèvent tout de même pas d'exceptions; pour ceux-ci, ce serait une grosse pessimisation. Gabriel Dos Reis insiste sur le fait qu'on fait selon lui erreur d'optimiser pour les cas noexcept du fait que même les types qui ne sont pas qualifiés noexcept, en pratique, ne lèvent à peu près jamais d'exceptions.

Ses propositions pour P0093 et P0094 respectivement.

On demande des précisions sur la proposition d'Anthony Williams, qui n'est pas présent ici. Axel Naumann explique les choix de design de cette approche; il parle d'un article de Ville Voutilainen qui parle des cas où on ne se débarrasse pas aisément de noexcept. Gabriel Dos Reis dit en avoir parlé avec Ville Voutilainen et être encore en désaccord, estimant qu'on optimise (erronément à ses yeux) le cas rare.

Axel Naumann pense que l'ajout d'un état vide, invisible en pratique (c'est un type parmi plusieurs) est une chose chouette; selon lui, ajouter un état vide explicite, choisi volontairement, ne simplifie pas le propos. Alisdair Meredith dit que ce qui l'irrite avec cet ajout est qu'il devra couvrir ce cas même s'il n'en veut pas. Axel Naumann dit que permettre un variant vide devrait être un feature, pas un cas d'erreur. Arthur O'Dwyer fait l'analogie que j'ai faite plus haut avec les pointeurs nuls, et indique qu'il y a des des cas où on veut un pointeur non-nul. David Sankel dit qu'avec tous les problèmes que nous avons eu avec des pointeurs nuls au fil des ans, il souhaite que nous ne modélisions pas à nouveau un tel type. Botond Ballo remet sur la table la possibilité d'avoir un optional<variant<Ts...>> pour représenter le cas vide.

Herb Sutter demande des précisions a David Sankel sur les possibilités d'optimiser un variant pour que son comportement évite le double-buffering. David Sankel explique comment y arriver quand certaines opérations clés sont noexcept. Herb Sutter rappelle son souhait de remplacer les union étiquetés, et dit vouloir un variant qui le permettrait de manière telle qu'elle serait une véritable option. Bjarne Stroustrup dit qu'une allocation dynamique de mémoire dans un variant empêcherait de l'utiliser dans les applications à « haute performance » où les union étiquetés sont utilisées (David Sankel dit qu'aucune des options sur la table n'agit ainsi); il ajoute que l'enseignement du type variant doit être simple et évident.

On discute de variant<int,float>, qui ne serait jamais invalide; il serait inacceptable de pessimiser un tel cas, et ajouter un état vide ne simplifierait pas le portrait. Certains parlent de Boost.Variant et de l'expérience terrain avec ce type, mais on ne veut pas nécessairement que std::variant soit tel que Boost.Variant. Quelqu'un propose d'ajouter explicitement une sorte de politique ou de type étiquette pour signaler le cas où le double-buffering est souhaité. Alisdair Meredith suggère un TS où on donnerait deux noms à deux types, on testerait les deux, et on ferait un choix basé sur celui qui donne les meilleurs résultats, ce serait une bonne idée.

Axel Naumann dit que la proposition du LEWG est de réduire les cas où un variant pourrait tomber dans un état invalide. On mettrait le variant dans un tel état seulement dans le cas où une affectation ou une affectation de mouvement aurait levé une exception. Cela impliquerait des tests volontaires de la part du code client, mais le code client saurait, de par son choix de types insérés dans le variant, que cette situation est possible (ou non). David Sankel trouve ce compromis intéressant : il devient alors si difficile de tomber dans un état invalide qu'on peut presque ne pas s'en occuper en pratique. Évidemment, ceci suppose que les constructeurs par défaut des divers types ne lèveraient pas d'exceptions. Arthur O'Dwyer demande si variant<float,int> aurait alors un état vide; Axel Naumann dit que oui, mais il ne tomberait jamais dedans. Alisdair Meredith dit trouver terrifiant qu'on n'ait presque jamais à se préoccuper de l'état vide. Axel Naumann dit que les types qui ne sont déjà pas nothrow-move-constructible nous mettent dans cette situation.

Gabriel Dos Reis demande si avec ce compromis, un variant<int,float> ou quelque chose de semblable, on obtient la garantie forte, telle qu'on pourrait l'utiliser dans du code de noyau de système d'exploitation? La réponse est oui. Gabriel Dos Reis si dit vraiment très heureux. Herb Sutter surenchérit. Axel Naumann dit qu'avec ce compromis, par contre, visiter un variant invalide pourrait lever une exception.

Nathan Myers demande si on peut copier « vers » un variant invalide et « d'un » tel variant. Axel Naumann dit oui.

Axel Naumann demande l'avis des gens sur place sur la question de la constructibilité par défaut ou non d'un variant :

Bjarne Stroustrup dit souhaiter que ce soit possible du fait que permettre un tableau de variant lui semble raisonnable. Mike Spertus est fortement opposé à l'initialisation sur le premier type du lot; cela lui semble être un cauchemar d'entretien. On échange sur diverses options, mais ce qui semble le plus populaire est de construire un variant par défaut dont la valeur est la valeur par défaut du premier type (j'aime pas beaucoup). Mike Spertus demande si un variant vide est possible; Axel Naumann pense que non, et ne le proposera pas. On se demande quoi faire si le premier type est void ou s'il s'agit d'un type qui n'est pas default-constructible; ça me semble être un aspect plus fragile de cette proposition, ce que j'ai indiqué assez fortement.

Nathan Myers demande si les types dupliqués sont possibles. Axel Naumann dit oui (ouf! Sinon, on ne couvrirait pas les union étiquetés).

Ville Voutilainen prend un vote. On a quelques contre mais aucun fortement contre; je vote pour (pas « fortement pour ») dû à mes réserves. C'est un gain. Jeffrey Yasskin dit qu'on va envoyer ceci à LWG pour éviter que LEWG ne nuise au processus. Axel Naumann demande si ça vaut la peine qu'il retouche la proposition existante pour inclure les fruits de notre discussion pour la passer à LWG cette semaine, et on dit oui.

David Sankel demande qu'on lui accorde un peu d'attention et amène sur la table un variant de niveau « langage » (plutôt que de niveau « bibliothèque »). Son écriture est enum union avec divers membres. L'accès à un membre passerait par :: et on aurait du Pattern Matching à l'aide d'un switch dont les cas seraient les types du enum union (il n'y aurait pas de break).

Il compare cette approche à une alternative déjà possible qui reposerait sur une classe de base abstraite et des enfants en spécialisant les services; il indique qu'on peut contourner cette approche par un dynamic_cast sur le type et des static_cast pour accéder aux services, mais t'sais... C'est de l'anti-polymorphisme. Il progresse dans sa démonstration pour voir le code qu'on doit écrire pour mieux faire avec une approche « bibliothèque » comme std::variant.

Ville Voutilainen demande si David Sankel est au courant d'une proposition de tuple étiquetés d'Eric Niebler. David Sankel dit que non. Eric Niebler dit que son approche n'élimine pas le Boilerplate alors il ne la recommanderait pas dans les cas visés par David Sankel.

Arthur O'Dwyer demande si cette approche se veut un remplacement pour std::variant. David Sankel dit non, c'est une proposition complémentaire. Bjarne Stroustrup recommande de ne pas utiliser switch et case dans ce cas, du fait que le comportement est radicalement différent. Aussi, Bjarne Stroustrup recommande de ne pas appeler cela enum union mais bien variant. On fait remarquer que les enjeux débattus pour std::variant apparaîtront ici aussi; David Sankel dit en être conscient, et avoir fait le choix explicite de ne pas discuter de ces questions dans sa proposition, celle-ci n'étant que préliminaire.

On échange un peu sur la mécanique du Pattern Matching mise de l'avant par cette proposition, en particulier sur le plan de la syntaxe (on utilise un peu de types à titre de variables).

Chandler Carruth dit vouloir la fonctionnalité proposée, mais ne pense pas qu'on puisse l'avoir dans le langage. Ça lui semble trop ambitieux, et il n'est pas sûr que ce soit faisable. David Sankel dit qu'il compte programmer au moins vingt ans encore, et que cette fonctionnalité améliorerait significativement sa vie. Herb Sutter ne se dit pas convaincu que cela soit infaisable. Bjarne Stroustrup dit souhaiter un changement terminologique mais ne pense pas non plus que ce soit impossible. Chandler Carruth dit rester convaincu que nous avons un problème de syntaxe plus profond. Bjarne Stroustrup reste en désaccord et pense que c'est faisable, mais ne pense pas qu'on va y arriver pour C++ 17; il exprime le souhait que les travaux se poursuivent.

Botond Ballo demande ce qui, dans la syntaxe proposée, pose problème. Bjarne Stroustrup rappelle qu'en C++ comme en C, un switch et un case est une forme de goto structuré; des mots comme inspect et match seraient selon lui plus à propos. Arthur O'Dwyer ouvre la porte sur du Pattern Matching avec des formules plus complexes. Quelqu'un demande si la portée des objets servant au Pattern Matching doit être délimitée par le cas couvert (question amusante). Daveed Vandevoorde indique qu'on a plusieurs cas de Pattern Matching dans le langage, la plus simple et la plus établie étant celle des boucles for sur des intervalles, et suggère que l'on unifie les travaux et les syntaxes. Chandler Carruth dit accepter qu'on l'ait considéré trop négatif et suggère qu'on sépare la proposition en deux morceaux, pour que le Pattern Matching soit traité à part; il souhaite qu'on puisse faire du Pattern Matching dans du code générique. Arthur O'Dwyer voit un lien à faire avec le destructuring (note personnelle : c'est drôlement intéressant comme remue-méninges ce soir!)

Herb Sutter suggère un vote sur la poursuite de l'idée générale proposée ce soir, car on n'aura plus la salle dans quatre minutes (il est presque 22h ici; je suis un peu claqué moi aussi, et ça recommence à 8h demain matin). On est tous fatigués et on a de la difficulté à formuler la question soumise au vote. On encourage la poursuite des recherches dont le domaine serait plus restreint (il y a quelques défavorables, plusieurs neutres et une majorité de pour/ fortement pour). On encourage la poursuite des recherches pour une solution complète (portait similaire, un peu plus favorable à l'oeil). Nathan Myers fait remarquer qu'on ne cherche pas une solution pour C++ 17. Bjarne Stroustrup recommande que le domaine du problème soit d'abord mieux défini. Un vote est pris quant à la recherche d'un variant de niveau « langage », et c'est globalement favorable.

On arrête à 22h8 par épuisement des participants.

Que tirer des échanges de ce soir? À mon avis :

Je suis pas mal fatigué. Il est 22h30 ici, 4h30 à la maison. J'ai une pensée pour mon épouse qui dort et qui est si belle. Temps de dormir...

Jour 2 20 octobre 2015

Passé tout droit. J'ai bien prépare l'alarme de mon réveil, mais j'ai oublié de l'activer. Sans commentaires.

Il faut très  beau ce matin. Je suis sorti prendre un café et un scone (leurs blueberries sont un peu comme nos framboises). J'ai croisé le sympathique Jonathan Caves qui suivait une démarche semblable à la mienne. Le café hawaiien est bon.

Nous sommes arrivés à la porte de CWG un peu avant 8h. Coincés à l'extérieur. Bavardé avec Jonathan Caves. Il travaille présentement sur les modules avec Gabriel Dos Reis et le tout avance bien; il semble que ce soit cette implémentation possible (Google en avait une autre) qui se dirige vers l'acceptation. Il m'a un peu parlé de l'évolution de son travail sur MSVC, de la refactorisation du code (parfois très ancien) que son implémentation contient, de l'exportation et de l'importation de templates à travers l'interface de deux modules, etc. C'est quelqu'un de très sympathique. Jonathan Caves me dit que se baigner ici est difficile : les rochers sont tranchants alors les gens qui vont à l'eau mettent des botillons de caoutchouc; aussi, il y a eu deux attaques de requins pas plus tard que la semaine dernière. Par contre, l'eau est chaude.

Ce matin, on commence à 8h15 car il a fallu attendre à 8h10 pour que l'on déverrouille la porte.

On y va. Juste avant que l'on commence, je renverse mon café sur la table (méga dégât). Heureusement, ma chambre est tout près alors je cours chercher une serviette pour éponger et pour couvrir le dégât le temps que ça sèche. On évite le pire.

Parlant de pire : heureusement qu'aucun électricien ne voit la configuration de prises de courant et d'adaptateurs sur la table, car nous serions sérieusement dans le pétrin.

Rewording inheriting constructors (core issue 1941 et al)

Richard Smith a retouché l'écriture de cette proposition pendant la nuit. Elle couvre à elle seule huit rapports de défectuosité distincts. C'est du beau travail; on compte appliquer le tout directement, puisque la caractéristique du langage que ce texte corrige est une caractéristique a priori brisée. En pratique, ceci corrige un bogue de C++ 11. Ok.

Core Issue 1776: Replacement of class objects containing reference members

Richard Smith a ausi retouché l'écriture de cette proposition pendant la nuit. La clé de son ajustement est la définition du concept interconvertible, qui décrit quand deux types ont la même adresse et peuvent être convertis l'un vers l'autre à travers un reinterpret_cast.

On a de la visite : Howard Hinnant, Alisdair Meredith, Jonathan Wakely et d'autres, donc des gens de bibliothèques. Nous sommes entourés  Il semble y avoir de la préoccupation de leur part quant à la formulation mise sur la table ici.

Jonathan Wakely est préoccupé des conversions parent/ enfant et tableaux. La formulation pourrait bloquer l'utilisation d'un vecteur, car on alloue un bloc de mémoire brute, pas un tableau, alors traiter l'adresse du tableau comme l'adresse de son premier élément et permettre d'avancer de plus d'un byte à la fois est un requis pour fins d'efficacité. De même, un tableau tab de dérivés D de forme Standard Layout devrait permettre de prendre &tab[0] et le traiter comme un pointeur de base B pour avancer comme dans un tableau de B, sauf si la base est vide (à cause d'EBCO). Son cas d'utilisation est un enfant qui dérive d'un struct C et ajoute des fonctions, pas des attributs, donc pour lesquels sizeof(D)==sizeof(B).

Mike Miller dit que cela recoupe la préoccupation qu'a EWG de permettre des appels de fonctions uniformes (f(obj,args...) deviendrait équivalent à obj.f(args...)). Jonathan Wakely dit que cela couvrirait bel et bien le cas visé ici, mais estime que brimer la conversion discutée ici lui pose problème.

Hubert Tong dit qu'il n'y a pas de cas qui empêcherait la bibliothèque standard d'implémenter la mécanique souhaitée ici. Jonathan Wakely met de l'avant qu'il ne faudrait pas empêcher le code client de le faire. Hubert Tong fait le constat qu'avec l'écriture existante, il serait impossible d'implémenter memcpy() en C++, mais est d'avis qu'on pourra traiter ceci ultérieurement.

Richard Smith parle de std::launder(), mais il se trouve que cette fonction ne crée pas un nouvel objet; elle permet de faire mentir le système de types. Jason Merrill indique qu'allouer un bloc de mémoire crée effectivement un tableau de type unsigned char. Mentir sur le pointé de ce type avec std::launder() est envisageable. Jonathan Wakely dit qu'il est d'accord pour qu'on écrive le texte de manière à empêcher quelqu'un de se promer hors d'un tableau ou de détruire le système de types. Richard Smith dit qu'il aimerait traiter cette question « à part », au cas où la sémantique de std::launder() ne serait pas exactement ce que l'on souhaite.

Jonathan Wakely dit qu'il s'est amusé à expliquer à Bjarne Stroustrup hier soir que vector est un cas de comportement indéfini. Semble qu'on aurait aimé voir sa face. On se bidonne un peu sur cet aspect du système de types.

Les gens de bibliothèque nous quittent. On revient sur std::launder(). Le cas d'utilisation visé est :

struct X { const int n; };
X *p = new X{3};
const int a = p->n;
new (p) X{5};                     // p does not point to new object ([basic.life])
                                  // because X::n is const
const int b = p->n;               // undefined behavior
const int c = std::launder(p)->n; // OK

... mais Richard Smith n'est pas d'avis que permettre l'arithmétique de pointeurs sur le résultat ne rejoint pas l'intention.

On débat des conversions T0*→void*→T1* lorsque les adresses sont les mêmes mais les qualifications cv diffèrent. Il faut faire attention à la formulation pour distinguer adresse et pointeur car un pointeur est typé.

Hubert Tong demande si on peut clarifier l'usage de std::launder() pour l'adresse du n-ième entier d'un tableau de n entiers. Je mentionne que ça ne devrait pas s'appliquer, du fait que le pointé n'était pas accessible à partir de l'objet original (l'adresse oui, le pointé non), mais Hubert Tong indique que les gens vont essayer quand même. On recoupe la préoccupation de Jonathan Wakely, à l'effet qu'allouer un bloc de mémoire devrait allouer un tableau de unsigned char. Jason Merrill discute de la différence entre contraindre et étendre les possibilités de conversion; std::launder() devrait nous permettre d'étendre nos horizons. Hubert Tong indique que si nous ouvrons trop grande la porte, l'analyse d'échappabilité (Escape Analysis) des alias ne sera plus possible et que perdre un byte de l'objet nous fera perdre l'objet entier.

Hubert Tong mentionne que std::launder() présume un objet existant, alors que Placement New crée un nouvel objet. Peut-être serait-il préférable de prendre l'angle de contraintes sur le lieu d'un Placement New? Il se peut que ça rende d'autres groupes de travail grognons, cependant. On discute brièvement de l'impact d'un Placement New sur un subobject (brrrrr...), mais c'est un sujet pour un autre jour.

On retravaille l'écriture du concept interconvertible. C'est abstrait et c'est difficile à exprimer de manière univoque. Jason Merrill mentionne un recoupement de §3.10 dans le standard, section qui explique les lvalue, rvalue et autres. Richard Smith pointe vers un paragraphe où on fait la nuance entre adresse d'un objet et pointer sur un objet. On travaille sur la formulation, ça avance bien. Richard Smith constate qu'une série de conversions d'adresses qui souivrait le chemin int*→void*→char*→void*→int* pourrait ne pas nous ramener vers le int* original avec la formulation proposée (c'est le passage par un char* qui déjoue le système; ça échappe à static_cast et on perd la garantie de préservation de l'adresse originale, constexpr et plein de trucs utiles comme ça).

On prend une brève pause car les cerveaux bouillent un peu. Je retourne quelques courriels.

On perd quelques joueurs du fait que la discussion sur les modules débute chez EWG. Jens Maurer nous revient (il était pris ailleurs pour la première partie du matin).

Core Issue 1895: Deleted conversions in conditional operator operands (retour, version 6)

Jens Maurer a fait une mise à jour du document pendant la nuit. On examine sa nouvelle formulation. Ceci permet d'alléger §13.6 p4 dans le standard. Ok.

D0012R1: Make exception specifications be part of the type system, version 5 (suivi, révision 5)

Jens Maurer indique que ça a passé hier à EWG, avec une seule opposition (Against, toutefois, pas Strongly Against). Il reste une préoccupation sur la clarté du standard quant à "pointeur de fonction" (sans noexcept) et pointeur de fonction (potentiellement avec noexcept). Je demande si on pourrait faire en sorte que LWG et LEWG soient conscientisés avant vendredi, pour éviter un autre vote contre « surprise »; Jens Maurer me demande d'informer Jeffrey Yasskin et Marshall Clow par courriel pour éviter les surprises.

On s'attaque à quelques dossiers mineurs en l'absence de quelques-uns de nos membres

Core Issue 2047: Coordinating "throws anything" specifications

Ce problème tient à l'ensemble des exceptions que peut lever une expression, du point de vue du compilateur (pas du point de vue d'une spécification dynamique d'exceptions, qui est une caractéristique qui sera selon toute probabilité supprimée à partir de C++ 17). La résolution proposée devra être adaptée pour en supprimer les spécifications dynamiques d'exceptions, par contre. L'air de rien, il y a du travail à faire ici (logique ensembliste sur les exceptions potentiellement levées par les divers éléments constitutifs de l'expression). Ok.

Aaron Ballman fait remarquer que pour operator new[](std::size_t,std::nothrow_t), on ne devrait pas lever std::bad_array_length alors que le standard actuel dit cela (vilain!). On devra revenir là-dessus puisque celle-là nous avait échappé dans les discussions pré-rencontre.

On bavarde sur la taille du standard actuel. Mike Miller indique qu'en 1998, Andrew Koening avait imprimé le standard entier (format postcript) sur une même page (772 pages conceptuelles sur une seule feuille de papier). On pouvait, en se concentrant, lire la page de titre. Ça prenait une vingtaine de minutes à calculer et à imprimer.

Core Issue 2082: Referring to parameters in unevaluated operands of default arguments

Ceci vise à rendre un truc comme void f(int n,size_t x=n); illégal tout en permettant des trucs comme void f(int n,size_t x=sizeof(n));, mais il y a plusieurs cas à considérer (empêcher d'utiliser this comme valeur par défaut d'une méthode d'instance – on ne sait pas s'il est cv au point où on s'en sert; le cas des prototypes de fonctions extern locaux à une portée qui entrent en conflit avec les prototypes de la même fonction dans une portée englobante, etc.).

Hubert Tong mentionne qu'avec l'écriture choisie, une expression reposant sur decltype(this) serait permise car this ne serait pas évalué, or on ne connaîtrait pas son type dû aux qualifications cv apparaissant ultérieurement dans la déclaration de la méthode. Good Catch. On s'en sort en retirant une référence croisée, pour que le texte bloque simplement l'utilisation de this dans ce contexte. Mike Miller mentionne que le point d'appel connaît les qualifications cv. Roger Orr mentionne le problème de sizeof(*this). On s'aperçoit qu'on s'en sort sur la base du point d'appel, alors c'est Ok finalement dans la mesure où this n'est pas unevaluated à ce point. On trouve ensuite un conflit avec §5.1.1 p4 et on revient sur nos pas. On a un problème de fond ici : le point où *this.m est évalué (et où on tient compte de cv sur this) ne semble pas couvert dans le cas de l'évaluation des valeurs par défaut des paramètres; ça va nous mener à un autre dossier, par contre, car ça sort un peu du problème discuté par cette propoisition.

Ok.

John Spicer suggère qu'on élimine carrément la notation permettant des prototypes extern avec paramètres ayant une valeur par défaut (ça sert surtout sur la frontière entre C et C++, mais c'est un peu limite justement), mais ce sera aussi un autre dossier.

On prend une pause, cinq minutes en retard. Mike Miller nous invite à être de retour à l'heure pile  Le groupe qui est allé s'occuper des modules revient un peu déprimé; il semble que le progrès ait été limité ce matin, un débat ayant eu lieu sur l'exposition sélective ou non de macros.

Je prends des nouvelles de ma belle cocotte Vayda, qui semble avoir eu un accident en éducation physique (rien de grave, mais des bobos, si j'ai bien compris). Petite marche à l'extérieur pour aller prendre une bouchée; les trottoirs imbriquent des coquillages ici, c'est charmant. Il y a un vendeur de noix de macadam dehors (achetez quatre livres de noix et obtenez une livre gratuite), mais ça ressemble à un attrape-touristes.

Jason Merrill est revenu avec un plat franchement sympathique qu'il a pris au Poke Bowl (!). Semble que le Poke soit une forme locale de ceviche, et il y avait un spécial sur le thon frais. Mioum! C'est un peu plus loin à pied, mais si j'ai un peu de temps j'irai essayer à un moment donné. Plus tard, ma belle Za me rappelle avec les enfants, et Ludo m'explique le son que fait un requin.

Un crash solide (Blue Screen) est survenu sur mon ordinateur juste avant le retour de la pause. Grrrr....

Core Issue 2084: NSDMIs and deleted union default constructors

L'écriture proposée considère le constructeur par défaut d'un union comme étant =delete si aucun de ses membres n'a d'initialisation implicite (avec {} ou ={}). Il y a des subtilités sur la formulation dans certains cas, alors on le met de côté pour le moment.

D0012R1: Make exception specifications be part of the type system, version 5 (en fait, révision 7)

On avait plusieurs cas de pointer to function qui devraient être des function pointer. Il y a une fine nuance mais elle est importante dans ce type de terminologie, car on veut une manière non-ambiguë de distinguer les pointeurs de fonctions qui peuvent être noexcept du cas des pointeurs de fonctions au sens général du terme. On a des nuances entre pointer to member function type et pointer to member of type function... Ouf! Mais c'est si subtil qu'on décide d'arrêter de se battre pour le moment.

Core Issue 2093: Qualification conversion for pointer-to-member handler matching

L'entreprise d'un des membres avait des réserves; cette entreprise n'est pas opposée à cette réécriture mais ne la veut pas sous la forme d'un rapport de défectuosité, car cela les contraindrait à l'appliquer et ils ne sont pas disposés à le faire pour C++ 14. Ce serait par contre acceptable pour C++ 17 en tant que nouvelle caractéristique. Ok.

Core Issue 2100: Value-dependent address of static data member of class template

Subtil. Il y a des trucs qui sont type-dependent (par exemple, les types dépendants dans un type obtenu d'un type générique), des trucs qui sont value-dependent (qui dépendent de la valeur d'une expression, comme dans le cas d'un tableau qu'on indicerait), et des trucs qui sont address-dependent. Ici, on cherche à raffiner la formulation qui explique ce que signifie dépendre d'une méthode de classe d'une classe générique.

Richard Smith fait remarquer qu'on pourrait indicer un tableau par l'adresse d'une méthode d'instance; faut en tenir compte dans la terminologie. John Spicer suggère une précision sur les cas pour lesquels ceci serait applicable. Jonathan Caves se questionne sur le calcul d'un indice par une soustraction de pointeurs sur des membres.

Richard Smith fait remarquer qu'on peut se trouver avec un cas comme operator+(T&) où le paramètre serait address-dependent. Cela affecte une partie de la description du sens donné à cette idée. On a quelques cas comme ça, alors on cherche une formulation correcte et simplificatrice (ça devient vite hors de contrôle). C'est le genre de cas limite où il est difficile de dire clairement si utiliser une référence signifie dépendre d'une adresse ou dépendre d'une valeur. C'est extrêment utile d'avoir les gens qui écrivent les compilateurs avec nous dans des moments comme ceux-ci.

John Spicer souligne le cas d'un type littéral (un struct traditionnel) initialisé avec une adresse constexpr et dont on extrairait ultérieurement cette adresse. Devrait-on indiquer que le struct entier est address-dependent? Richard Smith se dit d'avis que rendre le struct address-dependent donnerait une règle plus simple. On continue de se triturer les méninges puis Richard Smith fait remarquer qu'on recoupe un peu des définitions ailleurs dans le standard, alors on travaille pour harmoniser les définitions. Ça prend plus qu'une heure d'essais et de discussions.

Jens Maurer propose, pour le futur (pas aujourd'hui, faut y réfléchir) qu'on cherche une formulation qui permettrait d'exprimer le relais des propriétés d'un lvalue de manière générale; ça semble obtenir l'assentiment de tous.

Richard Smith nous sort une pièce d'anthologie avec huit ou neuf mots clés pour mettre en valeur un cas pathologique. On se bidonne. On identifie un cas pathologique de classes imbriquées, où la plus englobée affecte le côté address-dependent des classes englobantes. On décide de réfléchir un peu avant de continuer.

Mike Miller dit avoir reçu un courriel de Ville Voutilainen lui indiquant que les modules seront un TS. Cool!

Introducing a name for brace-or-equal-initializers for non-static data members

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0134r0.html

Il nous faut un terme pour nommer l'initialisation d'un NSDMI. On utilise présentement brace-or-equal-initializer et c'est long, lourd et déplaisant (on en a encore besoin à quelques endroits mais pas beaucoup). La proposition est default member initializer. Ok.

Core Issue 1776: Replacement of class objects containing reference members (révision 10)

On poursuit les travaux sur ce cas profond. Jens Maurer mentionne un inconfort sur le fait que l'on progresse sur ces points qui fonctionnent, sont massivement utilisés (je parle des cas de Cache-Friendliness et des besoins de SG14) mais pour lesquels nous n'avons pas préparé un document de design longuement réfléchi et débattu. Le bris (existant) de vector est un problème important, comme le rappelle Jonathan Caves, mais ce n'est pas un bris qui date d'aujourd'hui. Il nous faut vraiment une solution, mais à moyen terme.

On prend une petite pause. Jens Maurer a eu la gentillesse de nous apporter des bananes locales, très bonnes d'ailleurs. La moitié des gens restent sur place pour essayer de trouver des solutions aux problèmes non-résolus aujourd'hui. Je jette un coup d'oeil au pointage du match du Canadien, et semble qu'on se dirige vers une septième victoire consécutive, contre les puissants Blues par-dessus le marché!

On poursuit sur le même texte. On fait des retouches ici et là, et on a une formulation complexe mais qui semble fonctionner. Entre autres, elle permet la décrépitude de pointeurs (traiter un tableau comme un pointeur sur son premier élément) mais pas la dé-décrépitude, qui briserait la capacité d'un compilateur de réaliser toute forme d'Escape Analysis. Richard Smith nous fait encore rire en parlant de l'opérateur ternaire qui pourrait sélectionner, dans un même union, lequel des éléments serait actif.

Hubert Tong demande comment cette nouvelle formulation impacte ce qui est constexpr. On creuse un peu pour s'assurer que l'on n'a rien échappé. En particulier, il est possible pour une fonction constexpr de réaliser des affectations dans certains contextes, alors il n'est pas clair que l'on veuille bloquer, même par accident, le changement hâtif du membre actif d'un union. Le croisement avec §5.18 demande une attention particulière, et permet ce changement, mais on n'y a pas assez réfléchi pour qu'il soit évident que nous le souhaitons. Jens Maurer suggère que l'on interdise les comportements indésirables. Hubert Tong rappelle qu'on peut affecter un union à un autre union et, ainsi, modifier le membre actif sans y affecter une valeur à proprement dit.

On le remet sur le brûleur pour la nuit. Ça approche de la fin, mais faut encore travailler dessus.

Core Issue 242: Interpretation of old-style casts

Ouch. Les transtypages « old style » se font par une analyse en deux temps, qui permet d'examiner un ensemble de possibles et de choisir ce qui semble convenir. C'est pas mal avec ce qui ressemble à un reinterpret_cast, mais pas pour ce qui rejoint un static_cast. Quand les deux sont « possibles », faut une formule qui préfère static_cast. Le cas des const_cast intervient aussi : faut leur donner une chance sinon ils ne seront jamais choisis dans le processus analytique.

C'est difficile de rendre justice aux travaux ici, mais on clarifie plusieurs paragraphes pour que les règles de conversion soient claires et univoques. C'est très technique. Il y a un paragraphe dans le standard qui pose problème, au sens où passer par les règles qui y sont tend à aiguiller les conversions vers un chemin suboptimal ou inadéquat, mais on hésite à le déplacer plus loin dans la séquence de règles car l'écriture des paragraphes suivants commence par « Otherwise » et qu'il est difficile de bien analyser l'ensemble des conséquences d'un tel geste.

Jens Maurer a une idée : voir si on peut former une séquence de conversions valides. Si on y arrive, on ne pourra pas nécessairement la mettre en application, mais c'est un autre problème (si une conversion est ambiguë, on ne veut pas qu'elle soit appliquée après tout). Il va retravailler le texte et nous revenir car ça pourrait alléger significativement les cas à couvrir.

Core Issue 1776: Replacement of class objects containing reference members (suivi)

Richard Smith a fait un petit changement qu'on examine. Richard Smith entend qu'un objet, sur le plan notionnel, peut exister sans être « vivant » (être avant d'occuper un espace en mémoire ou après avoir occupé cet espace). Mike Miller cherche à clarifier que l'espace qui sera occupé par l'objet, ou qui a été occupé par l'objet dans le passé, n'est que de l'espace l'entreposage. Richard Smith liste des opérations qui peuvent être faites sur l'objet avant qu'il n'occupe officiellement un espace, comme par exemple prendre un pointeur sur une classe de base non-virtuelle de l'objet avant qu'il ne soit construit.

Il y a une nuance entre la notion de pointeur au sens de son utilisation (adresse typée) et au sens donné par le langage, s'adressant au compilateur (lieu d'un objet, qui peut s'y trouver ou non).

On s'arrête pour aujourd'hui; il est 17h5. On reprendra demain, car c'est une question de fond. Mike Miller nous parle brièvement du plan de match pour demain.

Après la séance de travail d'après-midi avec CWG, j'ai une rencontre avec Jon Kalb pour la possible organisation d'une classe de maîtres qui précéderait CppCon 2016 et qui porterait sur les enjeux de la programmation de systèmes à basse latence avec C++.

Je suis allé souper avec Dinka Ranns, Jon Kalb, Pablo Halpern, Aaron Ballman et Robert Douglas, mais l'objectif était d'examiner les opportunités pour construire la classe de maîtres susmentionnée avec Jon Kalb, qui est le maître d'oeuvre de CppCon. Le souper a coûté un peu cher selon mes standards, mais au moins c'était bon (du thon frais semi cuit avec une salsa de fruits locaux, et un peu de bière locale de bonne qualité). Je sais pas mal où je m'en vais si je compte proposer quelque chose pour 2016, et je connais les paramètres d'une telle classe. Entre autres, je comprends mieux qu'il serait avantageux que je propose aussi une présentation publique pour CppCon 2016 en même temps. Ce ne fut pas du temps perdu. J'ai aussi une meilleure idée de la progression générale de la standardisation de C++ et de ce qu'il est raisonnable d'espérer pour C++ 17 (il y a une part importante de politique, de non-technique ici).

Je suis arrivé à la rencontre de la soirée vers 19h40. C'est une bien plus petite audience que pour la séance d'hier sur variant (à l'oeil, nous sommes une quinzaine). C'est un sujet moins sexy, évidemment : comment formaliser, par des macros, le support (ou non) d'une caractéristique du langage (en particulier, des spécifications techniques) par un compilateur ou l'autre.

Clark Nelson fait remarquer que pour le moment, les TS sont supportées en entier ou pas du tout, ce qui explique que l'on ait une macro par spécification. La situation est différente pour des trucs plus profonds.

Certains suggèrent le cas où un compilateur passe de « ne pas supporter » une caractéristique, à « on le supporte », à « oups, on le supportait mais il y avait des bogues », à ...  et se demandent comment paramétrer les macros de manière telle que ces nuances puissent transparaître. Je me permets de souligner que le vendeur du compilateur dira en fait « nous estimons que nous le supportons maintenant, et nous acceptons les plaintes à partir de maintenant ».

(j'escamote plusieurs des débats ici; c'est principalement un débat politique)

Ça s'est conclu plutôt rapidement. J'ai déménagé mes pénates vers les travaux de LWG. On est un peu moins de vingt personnes, doit trois de CWG (Aaron Ballman, Hubert Tong et moi)

2424. 29.5 should state that atomic types are not trivially copyable

(j'ai manqué le début des débats)

Stephan T. Lavavej dit que N4148 devrait prendre plus de place à l'ordre du jour de CWG ou d'EWG car LWG en a besoin.

2309. mutex::lock() should not throw device_or_resource_busy

http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#2309

Il y aura des retouches terminologiques faites et ça devrait être Ok pour vendredi.

2363. Defect in 30.4.1.4.1 [thread.sharedtimedmutex.class]

http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#2363

C'est une clarification terminologique (on fait référence à un truc qui n'existe pas). Il y a des retouches syntaxiques à faire aussi pour lever quelques ambiguïtés.

2337. shared_ptr operator*() should not be noexcept

http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#2337

Selon Stephan T. Lavavej, exprimer noexcept ici va à l'encontre des pratiques de LWG. Ville Voutilainen dit que ne pas être noexcept serait surprenant pour bien des programmeuses et des programmeurs. Stephan T. Lavavej indique que l'opérateur * de unique_ptr n'est pas noexcept. Jonathan Wakely trouve une bonne raison technique (les Custom Deleters). Il y a un débat intéressant à savoir si appliquer noexcept est une règle ou une habitude dans le cas de fonctions dont le contrat est restreint; certains craignent, et ça me semble légitime, que cela crée des attentes chez les clients. Ville Voutilainen suggère à Nicolai M. Josuttis de placer la consigne en ce sens dans ses livres; Nicolai M. Josuttis dit qu'il ne descendra pas à ce niveau de détail dans un document imprimé.

760. The emplace issue

http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#760

C'est un duplicat, mais on parle d'un truc comme v.emplace_back(v.begin()) pour un vecteur v donné.

2510. Tag types should not be DefaultConstructible

http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#2510

Si on ne permet pas qu'un constructeur par défaut soit explicite, il est possible d'introduire des ambiguïtés avec un paramètre de valeur {}. Semble que CWG ait considéré ce problème réglé. Va falloir y revenir.

2456. Incorrect exception specifications for 'swap' throughout library

http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#2456

Le problème est que c0.swap(c1) exprimera ses contraintes de noexcept en termes de noexcept(swap(e,c1.e)) pour chaque élément e de c0 et de c1. Cela ne tient pas compte d'ADL. Un trait is_nothrow_swappable réglerait le problème.

2542. Missing const requirements for associative containers

http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#2542

Le requis de la spécification const ou son omission sur un comparateur dans un conteneur est sous-spécifiée. Certaines implémentations créent le comparateur à chaque utilisation, mais comme je l'ai fait remarquer, cela présume un comparateur sans états. Je ne pense pas que l'interface des conteneurs existants se prête à ça, car les conteneurs acceptent un comparateur en paramètre à la construction. Cela dit, c'est un monde bien différent ici  Le but visé est plus de se prémunir contre des usagers qui se plaindraient que de rendre la chose « béton ».

2426. Issue about compare_exchange

http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#2426

L'écriture dans ce cas laisse entendre que l'atomicité va plus loin que ce qu'elle fait réellement. Stephan T. Lavavej suggère de ne pas insérer d'exemple, du fait que les atomiques sont déjà un sujet pour experts, mais je fais remarquer que le problème soulevé tient a priori à une remarque d'un usager qui pensait, sur la base du texte, pouvoir faire plus que ce que nous permettons réellement, alors l'exemple me semble à propos. Marshall Clow dit qu'il est disposé à réécrire l'énoncé.

2541. [parallel.ts] Headers for ExecutionPolicy algorithm overloads

http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#2541

Jonathan Wakely va l'écrire.

2540. unordered_multimap::insert hint iterator

http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#2540

On le marque Ready.

(j'arrête ici, trop fatigué, mais c'était intéressant; il leur reste encore une quinzaine de minutes de boulot, plus un peu de travail sélectif pour ceux qui ont des trucs à écrire en vue de demain)

Il est 22h ici, 4h du matin à la maison, et mon corps me dit que c'est assez.

Jour 3 21 octobre 2015

J'ai réussi à placer mon réveil correctement ce matin. Ouf! Il faut encore une fois tres beau dehors; les amatrices et les amateurs de temps chaud et humide adoreraient, mais ici, le temps humide est moins douloureux qu'au Québec car il y a toujours du vent, du moins sur le bord de la mer.

Il y a un groupe de personnes qui bavardent près de ma porte de chambre; si j'essayais de me reposer, ça me ferait grogner (il est 7h du matin) mais dans le contexte, c'est un détail.

Jonathan Caves a posté une photo de la carte postale sur https://instagram.com/p/9KFL6WTb9q/ si ça vous intéresse

Jens Maurer a apporté une carte postale pour Beman Dawes, qui n'est pas présent cette fois. C'est plutôt amusant : on y voit l'hôtel, et Jens Maurer y a ajouté des flèches (qui convergent toutes au même endroit, évidemment) indiquant l'endroit où se rencontrent les groupes de travail. On signe la chose.

Andrew Sutton vient nous voir. Il ne pourra pas travailler avec nous ce matin car il est sollicité pour des questions quant aux concepts dans un autre groupe de travail. On lui souhaite bonne chose. Jon Kalb vient aussi s'asseoir avec nous; je ne sais pas comment il trouve son expérience.

On bavarde un peu de ce qui s'est passé lors de la rencontre de soirée du groupe LWG hier soir.

Jason Merrill indique que Torvald Riegel, qui est absent cette semaine, a écrit un truc sur le Forward Progress (section 2 de http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0072r0.pdf). Il semble qu'EWG ne veut pas le regarder, indiquant que c'est une question de formulation (donc CWG), mais c'est pas un petit truc et faut être certain que c'est sur notre table. On va essayer de voir d'ici demain ce qu'on fait avec ça; Torvald Riegel propose de nous le présenter par vidéoconférence mais il est en Allemagne (douze heures de décalage).

Core Issue 1776: Replacement of class objects containing reference members (révision 21)

Richard Smith a retravaillé quelques passages. Faut faire attention de ne pas briser les cas d'utilisation comme std::optional<T>... et s'est aperçu en nous l'expliquant que c'est ce qu'il était en train de faire. On se bidonne.

Hubert Tong fait remarquer qu'en pouvant remplacer un membre d'un union qui aurait lui-même un membre const, on ne peut plus vraiment compter sur le const. Richard Smith dit qu'on peut accéder à la donnée par l'ancien nom via std::launder(). On constate que le nom d'un objet ne le nomme pas nécessairement (il y a des cas pathologiques...).

Dinka Ranns mentionne le cas du Common Initial Sequence. Jens Maurer dit que ça n'a pas d'influence, c'est seulement pour fins de lecture. Jason Merrill dit que ça risque de briser gcc, du fait que certains blocs débutent par un union. Hubert Tong dit que C fait la même chose, et recommande de ne pas rendre C++ plus « relaxe » que C. On est plusieurs à se dire Oups! Le code est brisé depuis longtemps...

Jason Merrill fait remarquer que le texte proposé pose problème au sens où il ne traite pas d'alignement. Richard Smith dit que c'est un vrai problème, mais qu'il aurait préféré traiter ce problème de manière distincte (l'idée avec le texte actuel est de faire fonctionner un truc comme std::optional<T>). Mike Miller dit qu'il préférerait qu'on traite l'alignement dès maintenant. Hubert Tong fait remarquer que l'on va bientôt, légalement, pouvoir implémenter plusieurs optimisation a priori illégales comme SSO... Richard Smith publie un exemple d'anthologie pour §1.8 p2 :

struct X { const int n; };
union U { X x; float f; };
void tong() {
  U u = {{ 1 }};
  u.f = 5.f;                          // OK, creates new subobject of 'u' (9.5)
  X *p = new (&u.x) X {2};            // OK, creates new subobject of 'u'
  assert(p->n == 2);                  // OK
  assert(*std::launder(&u.x.n) == 2); // OK
  assert(u.x.n == 2);                 // undefined behavior, 'u.x' does not name new subobject
}

...et on a beaucoup de plaisir pendant quelques minutes.

Core Issue 242: Interpretation of old-style casts (suivi)

Jens Maurer a travaillé fort sur celle-là. Il a retravaillé §5.2.9 p4 pour qu'il soit moins attirant et permette aux autres clauses de s'appliquer en temps opportun. On travaille sur les détails. Il a porté sa tactique sur la possibilité d'établir une séquence implicite de conversion, ce qui indiquerait qu'un static_cast aurait suffi.

Richard Smith se questionne sur le recours à la construction d'une séquence implicite de conversion pour une initialisation directe. On y reviendra

Core Issue 2084: NSDMIs and deleted union default constructors

C'est un cas niche mais sous-spécifié dans le langage. On cherche une formulation claire. On veut quelque chose d'aussi efficace que C par défaut, mais qui donne la flexibilité de C++ quand on le souhaite. La question est : quels sont les cas qui font qu'une classe ou un struct contenant un union perdra implicitement son constructeur par défaut?

Roger Orr se questionne sur la localité des changements proposés : on parle de membres internes d'un union anonyme dans un struct, alors il suggère un déplacement vers §12.1 p4.6. Jens Maurer suggère que réorganiser cette section soit une bonne idée, mais serait un dossier distinct.

Ok. On y va avec celle-là.

Core Issue 2100: Value-dependent address of static data member of class template (suivi)

C'est amusant : le texte de celle-ci est à 100% fait d'ajouts et de suppression (il n'y a plus de texte original!). Jens Maurer a ajouté le concept d'address-sensitive-type pour mieux définir ce qui est entendu ici. Les idées de value-dependent et d'address-dependent touchent essentiellement à ce qui est constexpr.

Richard Smith fait valoir que l'on n'est vraiment address-dependent que si on se trouve en mémoire statique, par définition. Mike Miller fait remarquer que les listes d'initialisation devraient faire partie de la liste des cas couverts. Richard Smith constate qu'on a des cas de pessimisation possibles, ce avec quoi Jens Maurer se dit d'accord.

John Spicer fait valoir qu'on a une clause assez complexe pour avoir besoins de listes les cas par des puces.

Mike Miller mentionne que l'on va regarder http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0138r0.pdf avec Gabriel Dos Reis au retour de la pause.

Pendant la « pause », j'ai retourné quelques courriels, lu le texte de Gabriel Dos Reis (un court texte), fait quelques tests, et travaillé sur la présentation des Flat Containers (mais j'en ai encore beaucoup à faire).

Construction Rules for enum class Values

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0138r0.pdf

Gabriel Dos Reis explique qu'il est possible de faire, avec des enum class sans valeurs, des petits alias simples qui sont à toutes fins pratiques des types forts, pas des alias, mais ils sont difficiles à initialiser proprement sans avoir recours à un static_cast. Gabriel Dos Reis suggère qu'on permette l'initialisation avec accolades pour le substrat, ce qui devrait éviter des erreurs de narrowing.

Gabriel Dos Reis propose une adaptation à la formulation existante pour tenir compte de cet ajustement. Aaron Ballman souligne que ceci :

enum class byte : unsigned char {};
void f(int);
void f(byte);
void g()
{
   f(3); // f(int)
   f(static_cast<byte>(3)); // f(byte)
   f(byte{ 3 }); // f(byte)
   f( { 3 } ); // ambigü
}

... serait ambigu. Gabriel Dos Reis dit que oui, et c'est correct, car dans ce cas un static_cast lèverait l'ambiguïté. Aaron Ballman et Richard Smith suggèrent des retouches au texte sur les séquences d'initialisation. John Spicer demande si la restriction aux enum sans valeurs énumérées est adéquate ou si ce n'est pas un peu arbitraire. Gabriel Dos Reis dit que les cas qui le préoccupent sont ceux des enum sans valeur.

Aaron Ballman suggère qu'il y ait des cas pervers où l'initialisation généralisée deviendrait ambiguë pour du code existant. Il faudra ajouter une clause dans les annexes portant sur la compatibilité. Richard Smith demande des explications pour l'absence de valeurs énumérées. Gabriel Dos Reis explique que cela explicite, à ses yeux, l'intention. Richard Smith donne des cas que ça briserait dans le code existant. Jens Maurer indique qu'une valeur énumérée est un rvalue, mais que dans certains cas une expression constexpr est un lvalue ce qui jouerait peut-être des tours ici. Richard Smith dit qu'il y a une question de portée à régler aussi.

John Spicer demande s'il y a un mauvais côté à « étirer » la proposition aux cas des énumérations avec valeurs énumérées, mais on convient que ça mène à des pratiques de programmation discutables (utiliser des littéraux numériques plutôt que des symboles). Hubert Tong demande s'il serait intéressant d'enrichir la syntaxe des enum pour permettre l'ajout de constructeurs paramétriques explicites. Gabriel Dos Reis dit que ce serait une autre proposition.

Hubert Tong mentionne que le code résultant de ce changement cacherait en fait des pratiques de programmation que certain(e)s considéreraient discutable (des transtypages explicites, qui accrochent durant une revue de code). Gabriel Dos Reis dit qu'avec les accolades, on ne peut rien faire de mal. Richard Smith prend la perspective de la sécurité, et craint qu'on risque de perdre avec ce changement ce qu'on a gagné avec les enum class.

Jens Maurer construit un exemple pour montrer que le type faible (enum) aurait ensuite des règles de conversion plus fortes, dans certains cas, que le type fort (enum class). On discute fort. L'un des irritants est qu'il y a des propositions pour obtenir un typedef fort, mais que ça ne passe pas dans EWG (il y a de la résistance prononcée). Gabriel Dos Reis estime qu'on a un cas de typedef fort, celui-ci, mais qu'on impose du bruit syntaxique. Richard Smith voir un lien avec http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4094.html qui a participé à un débat important sur l'allègement syntaxique lors d'un return d'un type dont le constructeur est explicite.

Un débat assez costaud sur le rôle de chaque groupe de travail s'ensuit. J'ai escamoté ceci car je pense qu'il s'agit de gestion interne. C'est intéressant, par contre. Gabriel Dos Reis prend les suggestions faites à CWG et va revenir à EWG. C'était ... tendu.

Core Issue 1992: new (std::nothrow) int[N] can throw

Aaron Ballman mentionne que ceci appelle operator new[] et, si on remplace int par T, peut appeler plusieurs fonctions (constructeurs de T entre autres). Hubert Tong mentionne que std::bad_array_length est généré « magiquement » par le compilateur et est un cas à part. Hubert Tong mentionne aussi que §15.4 p15 est normativement incorrect présentement.

Aaron Ballman va la retravailler et nous revenir.

D0012R1: Make exception specifications be part of the type system, version 5 (suivi)

On revient sur ce point car Hubert Tong a remarqué un problème dans le cas où une fonction retourne une fonction noexcept. Faut revenir dans le standard-même à §15.4 p1, et il faut ajouter dans D0012R1 le passage modifié.

Core Issue 2047: Coordinating "throws anything" specifications (suivi)

Hubert Tong a remarqué un problème dans ce cas aussi. Selon lui, c'est le premier ajustement à traiter.

Mike Miller indique que l'on pourrait revoir Alisdair Meredith en début d'après-midi pour retoucher un texte. Pour le reste, on poursuivra le travail engagé déjà.

Ouf, un gros matin, et beaucoup d'action.

Sur l'heure du dîner, j'ai travaillé un peu sur l'une des présentations que je dois faire cette semaine, puis je suis sorti me chercher quelque chose à manger. Il très chaud dehors, et il n'y a que peu de vent aujourd'hui alors c'est plutôt déplaisant pour quelqu'un comme moi, mais ce serait probablement plaisant pour plusieurs de celles et ceux qui lisent ceci. Sur une des pierres marines que j'ai croisé, un crabe se prélassait au soleil.

J'ai eu le plaisir de parler un peu avec mon amoureuse et avec les plus jeunes. On ne s'en sort pas : la fibre « papa » et forte, et je m'ennuie vite des miennes et du mien.

On recommence avec Alisdair Meredith, qui a passé l'heure du dîner dans le local avec moi et Mike Miller pour retravailler ses formulations en vue de la discussion

D0001R1: Remove Deprecated Use of the register Keyword

Alisdair Meredith explique les principaiux changements :

Ok. Je ne pense pas que ce changement va changer grand-chose, mais on verra bien avec l'expérience concrète.

D0002R1: Remove Deprecated operator++(bool)

Alisdair Meredith explique les principaiux changements :

Hubert Tong mentionne que l'on ne tient pas compte de cv (en fait, de v) ici. Richard Smith fait remarquer que nos définitions de types arithmétiques au complet souffrent de ce problème. On convient qu'il s'agit d'un problème préexistant, et qu'il faudra le régler. Cela ne devrait pas affecter la proposition.

On fait un peu de retouches en périphérie, pour des paragraphes affectés de manière indirecte par le changement. Dans bien des cas, ça allège simplement le texte.

Ok. Je ne pense pas que ce changement va changer grand-chose, mais le standard s'en portera mieux.

1986. odr-use and delayed initialization

On cherche la bonne relation pour l'ordre induit par les dépendances à l'initialisation entre objets statiques, thread_local et automatique. John Spicer laisse entendre qu'on pourrait se baser sur le comportement observables des odr-usage, Richard Smith pense que c'est une option, mais je ne suis pas convaincu et Jason Merrill non plus.

Hubert Tong se questionne sur les risques de dépendance circulaire avec la formulation existante. Jason Merrill me fait remarquer que l'intialisation d'une variable peut parfois dépendre du début de l'initialisation d'une autre sans nécessairement dépendre de la fin de celle-ci.

À suivre.

2121. More flexible lambda syntax

Permettre d'omettre les parenthèses d'une λ sans paramètres de manière générale, pas seulement dans les cas banals existants.

(Aaron Ballman doit quitter et je me trouve à éditer le Wiki; j'espère que je ne ferai pas de bêtises)

1955. #elif with invalid controlling expression

Question de compatibilité avec C.

2035. Multi-section example is confusing

Changement d'ordre éditorial, pas encore fait.

2114. Missing description of incompatibility from aggregate NSDMIs

Changement d'ordre éditorial, pas encore fait.

1518. Explicit default constructors and copy-list-initialization

Ceci recoupe les discussions de LWG hier soir, portant sur la construction par défaut des types étiquettes qui pose problème avec {}, syntaxe trop gourmande. On discute de revenir sur une décision du passé.

(Jens Maurer revient; je lui repasse le contrôle du Wiki)

Jason Merrill exprime des craintes à l'effet que ce retour en arrière briserait du code existant (il réfléchit à ce que ça pourrait donner et semble à l'aise, finalement)

Mike Miller dit avoir une résolution possible, proposée par Richard Smith sur la liste de réflexion. Il nous reviendra avec un texte. Ce sera un hybride entre les suggestions de Jason Merrill et Richard Smith.

1743. init-captures in nested lambdas

On prend ça tel que. Ok. NAD.

2008. Default template-arguments underspecified

Jason Merrill suggère que l'une des formules soit élaguée. Roger Orr indique que la formule « offensante » est dans une note accompagnant un exemple, et se demande s'il est sage de la retirer. Je pense qu'on est d'accord pour la retirer tout de même. Mike Miller s'en occupera. Ok, classé.

2116. Direct or copy initialization for omitted aggregate initializers

Jason Merrill indique que l'on vient de déterminer que c'est un cas de direct-initialization. Richard Smith pense qu'on parle plutôt de copy-initialization. Ça semble être le cas (faut le donner à Richard Smith, éditeur du standard, il doit l'avoir lu souvent). Mike Miller va le faire.

On prend une pause. Mike Miller nous informe que demain, nous examinerons en vidéoconférence la section 5 de p0072r0 par Torvald Riegel.

Mike Miller nous indique avoir reçu un courriel de Ville Voutilainen en lien avec les échanges sur le texte de Gabriel Dos Reis ce matin. On examine la réponse d'EWG pour voir s'il est possible de progresser.

On échange sur le sujet avant de faire revenir Gabriel Dos Reis et de poursuivre les échanges du matin. On échange sur les effets (certains plutôt positifs) de la proposition; je fais part de mon expérience avec quelques autres langages. Jonathan Caves mentionne des cas d'utilisation dans son entreprise.

Richard Smith mentionne que ne pas permettre de valeurs sentinelles dans l'énumération brise des cas d'utilisation légitimes. On échange sur le sujet. Roger Orr mentionne le cas du return dans ce cas, qui entre en conflit direct avec un autre cas plus général. On constate quelques cas supplémentaires où la syntaxe demandée jouerait des tours, p. ex. : remplacer une liste d'initialisation mono-membre dû à l'ordre dans lequel les séquences de conversions procèdent; faudrait modifier les règles existante des séquences de conversion en introduisant un nouveau concept pour éviter ceci. On peut le faire.

D0012R1: Make exception specifications be part of the type system, version 5 (suivi)

Jens Maurer a fait des retouches pour préciser le sens de « un ensemble de types pouvant être levés en tant qu'exceptions ». C'est une construction langagière inexistante, mais il a trouvé une piste sur la base des spécifications noexcept des fonctions, quand il y en a.

David Krauss dit avoir implémenté quelque chose de semblable mais se questionne sur les transtypages de pointeurs de fonctions avec cette nouvelle syntaxe. Jens Maurer mentionne que pour le moment, transtyper perd la qualification noexcept.

Ok. On essaie de faire avancer cela vendredi. Ouf!

On échange ensuite sur une proposition portant sur les modules, mais qui ne semble pas tout à fait prête pour le moment. Mike Miller prévoit une téléconférence autour du début du mois de décembre.

1710. Missing template keyword in class-or-decltype

Selon la grammaire existante, l'écriture suivante :

template<typename T> struct D : T::template B<int>::template C<int> {};

... ne définit pas une classe. Le recours aux template ici et là est difficile à tirer de manière univoque à partir de la grammaire. Jens Maurer préférerait retourner à l'écriture pour ce que nous avons sur la table. Maxim Kartashev suggère des pistes, et mentionne le cas d'un destructeur (pour signifier un cas particulier de class-name) suivi de < qui n'est pas couvert dans le texte.

1930. init-declarator-list vs member-declarator-list

On a une règle qui devrait s'appliquer aussi à mutable pour les union anonymes dans un namespace anonyme, mais ne le fait pas pour des raisons grammaticales. Ça semble être une retouche facile à faire, impliquant principalement inverser partiellement un changement. Mike Miller s'en charge. Ok.

2017. Flowing off end is not equivalent to no-expression return

Le texte existant indique « Flowing off the end of a function is equivalent to a return with no value... » mais c'est faux car, dans les mots de Richard Smith, « ...a return with no value is ill-formed in a value-returning function but flowing off the end results in undefined behavior ». Faut toutefois retravailler la formulation qui est imprécise (elle parle de valeur, mais c'est plus ou moins à propos).

554. Definition of "declarative region" and "scope"

Ceci a été soumis en 2005, et le monde a bien changé depuis. L'exemple motivateur original était :

int j = 24;
int main()
{
   int i = j, j; // portée déclarative du 1er j: tout. Pour le 2e j: les accolades
   j = 42;
}

Mike Miller fait remarquer qu'on a eu plusieurs autres soumissions sur la question des régions déclaratives depuis, par exemple dans un namespace réparti sur plusieurs unités de traduction distinctes. On va essayer de traiter le tout de manière cohérente. Jens Maurer est d'avis qu'on n'a pas touché à ça depuis 2005, c'est trop épeurant. John Spicer a l'impression qu'on a peut-être ajouté à ce dossier depuis. Jens Maurer va jeter un coup d'oeil à l'ampleur de la tâche. Entre autres, il se peut que le traitement des λ soient incorrectement traités.

1928. Triviality of deleted special member functions (inspiré de 1734. Nontrivial deleted copy functions)

Amusant. On nous réfère à https://isocpp.org/files/papers/n4148.html car, dans l'était actuel des choses, une classe est TriviallyCopyable quand ses opérateurs de copie et de mouvement sont... supprimés.

Hubert Tong fait remarquer que la question de l'accessibilité à ces fonctions est une question de contexte. Jason Merrill ajoute que TriviallyCopyable devrait être pour sa part une propriété du type.

Jens Maurer indique que la demande tient au fait que les atomiques ne veulent pas être TriviallyCopyable, mais que la formulation leur accorde ce statut. Hubert Tong et Richard Smith font remarquer que la formulation proposée pour 1590. Bypassing non-copy/move constructor copying règlerait cette question. Jens Maurer suggère qu'on procède; cela semble provoquer l'assentiment général. On souhaite avancer (yay! Une pierre, deux coups! Ça va faire plaisir à bien des gens  ) mais arrive 1496...

1496. Triviality with deleted and missing default constructors

Ce dossier est un cousin des précédents, mais il demeure distinct. On peut observer la trivialité d'une classe par un autre mécanisme. On n'a pas encore réglé 1928 et 1734... Richard Smith mentionne que tout ce qui, dans le standard actuel, parle de trivialité devrait être revisité.

Jens Maurer mentionne qu'on pourrait fermer 1928 en tant que NAD, mais attaquer ensuite le coeur du problème. On accepte son idée.

Jason Merrill s'offre pour prendre en charge la formulation de celle-ci.

1946. exception-specifications vs pointer dereference

Richard Smith suggère NAD du fait que le mécanisme de spécifications dynamiques d'exceptions est déprécié, et que l'exemple fonctionnerait avec noexcept.

2010. exception-specifications and conversion operators

On suggère NAD pour celle-ci, à moins que P0012 ne dérape cette semaine. La conversion semble noexcept. Jens Maurer indique qu'on pourrait, si P0012 passe, considérer le problème résolu, ce qui serait plus exact.

Core Issue 2100: Value-dependent address of static data member of class template (suivi)

Jens Maurer a ajouté des puces pour fins de lisibilité. Ça ne nuit pas. Jason Merrill se demande comment une initializer_list pourrait être address-dependent puisqu'on ne peut prendre son adresse. Jens Maurer dit qu'initialiser un des éléments de la liste rend la liste address-dependent. Mike Miller dit qu'initialiser un struct qui serait address-sensitive avec une telle liste aurait pour conséquence de rendre ce struct address-dependent.

C'est un combat d'exprimer ce concept de manière précise. Richard Smith suggère une formulation pas si mal, et qui permet d'alléger la formulation avec plusieurs puces.

On arrête là pour cet après-midi. Mike Miller va écrire à Ville Voutilainen et à Gabriel Dos Reis pour exprimer les préoccupations résiduelles de CWG, puis suivant leur réponse, nous explorerons leur formulation. Daveed Vandevoorde vient bavarder et soutient qu'il se peut que le cas du return {3}; ne serait pas un problème (à réfléchir).

Je bavarde un peu avec Mike Miller pour voir quel serait la meilleure manière d'aborder la question de la gestion de la taille de la pile d'exécution d'un thread au démarrage (question complexe), mais ce qu'il me suggère, je l'ai déjà fait.

Je prends un peu de temps avec mon amoureuse, puis je vais me chercher une salade en face (très correcte : papaye, chou, arachides, crevettes, tomates, lime, piment, ail... Mioum!). Le soleil se couche tellement vite aux abords de l'équateur : quelques minutes et il plonge dans la mer!

En attendant le début de la séance de la soirée (portant sur SG14, le groupe de travail sur les systèmes à basse latence auquel je participe beaucoup car il touche le monde du jeu et des systèmes en temps réel, donc les trucs que j'enseigne), je peaufine une brève présentation que je dois faire vendredi matin devant EWG pour soutenir un tiers. Je n'ai pas encore terminé quand le temps vient de me déplacer là où se tient la séance de la soirée.


Autant vous le dire d'office : ce fut une soirée surréaliste. Allons-y de manière chronologique.

Je suis arrivé dans la grande « salle » extérieure (je vous rappelle qu'il n'y a pas de murs ici, du moins pas pour le lieu de rencontre en grands groupes : on a un toit et des paravents, c'est tout) un peu moins de dix minutes avant le début des travaux et il n'y avait que peu de gens. Bon, faudra voir, peut-être que les questions associées aux systèmes à basse-latence intéressent peu les gens ici, ou peut-être que les gens comptent arriver plus tard. Il faut savoir qu'il y a deux séances de travail ce soir, l'autre portant sur les contrats sémantiques, un sujet qui m'intéresse aussi, alors il est clair que les gens se répartiront entre les deux lieux où se tiennent des travaux.

Truc particulier : il y avait une sorte de clôture improvisée devant le chemin d'accès vers notre salle de rencontre, avec des affiches indiquant « événement privé ». Bon. Un employé de l'hôtel arrive, je passe la clôture, il me sourit. Je m'installe avec les quelques collègues déjà présents, dont Hubert Tong et Billy Baker, auxquels s'ajoute peu de temps après Thomas Köppe, et il devient vite clair que nous seront nombreux (plus d'une quarantaine, à l'oeil), et je vais me chercher un verre d'eau froide car il fait vraiment très chaud ici aujourd'hui, même une heure après le coucher du soleil.

Michael Wong, qui animera la soirée, vient nous voir Billy Baker et moi, de même qu'Alex Rosenberg de Sony, et nous demande d'aller sur la scène car il souhaite que nous soyons les intervenants « semi-panel » pour la rencontre. Je range mon laptop et on va sur la scène. Un collègue d'Alex Rosenberg, Michael Spencer, se joint à nous. Être au coeur des débats, c'était pas le plan de la soirée, même si ça ne me dérange pas.

Les gens se répartissent dans la « salle ». Michael Wong commence à présenter son plan de match pour la soirée, et à dire qui nous sommes tous les quatre. Le micro ne fonctionne pas alors il faut parler fort (n'oubliez pas : nous sommes une quarantaine, en plein-air). Tout à coup, la musique commence derrière les paravents et un animateur de foule commence à chanter des pièces... disons qui ont fait leur temps. Eh oui : l'événement privé est un mariage, à vingt mètres de nous!

Michael Wong a tenu le fort pendant une dizaine, peut-être une quinzaine de minutes. Les gens dans la salle se sont rapprochés. Pas de micro, c'était tout un combat. Faut comprendre aussi que tout le monde ici est plutôt gentil, et que nous ne voulons pas que notre rencontre archi-technique entre en conflit avec un mariage (on ne leur veut quand même pas de mal  ). Vient un temps où l'animateur décide de se débarrasser de nous et se met à chanter très fort, très près de notre humble rencontre. On l'a pris en riant et on a demandé à l'hôtel de nous ouvrir une des grandes salles de réunion fermées disponibles. On nous a apporté de l'eau et il y avait de la climatisation, et notre groupe entrait « juste » (quelques personnes ont dû s'asseoir en périphérie) alors je dirais qu'on a gagné au change, et que le mariage (qui bat encore son plein non-loin de ma chambre au moment d'écrire ceci) semble bien se dérouler.

Je n'ai évidemment pas pris de notes ce soir, était beaucoup sollicité. Un peu comme à CppCon 2015, je me suis trouvé au coeur de la tourmente car mes chiffres un peu tristounets sur les caractéristiques des exceptions à l'exécution (vitesse, coût en espace) font beaucoup réagir. Ce fut encore une fois le principal sujet d'attention ce soir.

Il n'y avait pas que ça, heureusement, car du groupe SG14 sont sortis plusieurs propositions intéressantes déjà, et il y avait donc beaucoup de trucs riches en contenu à discuter.

Plusieurs aspects intéressants de la rencontre :

Les gens ont beaucoup participé, de manière constructive, et ont véritablement enrichi les propositions déjà mises sur la table de manière sommaire. Ce fut, à mon avis, très rentable sur les plans intellectuel, technique et politique comme soirée.

À la fin de la rencontre, Jeffrey Yasskin est venu nous voir, Billy Baker, Michael Wong et moi-même, pour nous informer que les présentations destinées au groupe qu'il dirige (LEWG) sont prévues à l'horaire tôt demain matin, dès 8h en fait. Cela vient de paver la voie pour le début de ma matinée. C'est un peu moche par contre, car la rencontre avec Torvald Riegel m'intéresse beaucoup, et je pense qu'après peut-être Jens Maurer, dans CWG, je suis le plus familier avec les questions de parallélisme et de concurrence (je peux me tromper ici; je base mon impression sur les discussions auxquelles j'ai participé, mais c'est peut-être un échantillon invalide).

Jour 4 22 octobre 2015

Ok. Pour aujourd'hui, faudra être tolérant(e)s car je n'ai pas pu écrire ce qui se passait au fur et à mesure, étant sollicité pratiquement 10% du temps. De mémoire, voici un peu le portrait de la journée.

Tôt ce matin, je me suis préparé pour ma présentation du matin devant LEWG. Je devais présenter une proposition de Sean Middleditch, un chic type de SG14 et artisan de l'industrie du jeu, sur un conteneur utile dans le monde du jeu mais aussi dans d'autres contextes. Cette proposition était « niche », mais pas tant que ça; par contre, elle détonnait un peu des pratiques existantes du standard alors je vous m'assurer que mon argumentaire soit solide (l'air de rien, présenter le travail d'un autre, c'est pas un truc qu'on voudra gâcher).

Je suis sorti me chercher un café et une bouchée, puis je suis allé m'installer à la salle de LEWG, bien plus grande que celle où CWG officie. Vers 8h, les travaux ont commencé formellement. J'ai appris que ma laveuse était décédée à la maison et qu'il fallait la remplacer (bobo au portefeuille!) alors ma belle Za est allée magasiner et devait me faire un rapport par Skype pour qu'on décide ce qu'on ferait.

Les modalités chez LEWG diffèrent fortement de celles de CWG. Chez Core (CWG), c'est un travail de rigueur et de grande abstraction; chez LEWG, c'est aussi un travail de rigueur et d'abstraction bien sûr, mais on se trouve plus en amont de la production de nouvelles idées alors on ne va pas autant dans le détail, alors que chez CWG on joue le rôle de dernier rempart avant publication donc les erreurs font plus mal.

La manière de travailler est aussi fort différente. Jeffrey Yasskin, qui est à la tête de LEWG, sépare le grand groupe en sous-groupes de 6-7 personnes et distribue les dossiers pour que l'on débatte productivement, puis on se rassemble tous ensemble pour entendre les conclusions des sous-groupes, prendre les questions ouvertes, débattre et éventuellement tenir un (ou plusieurs) votes.

Avant de me lever pour aller me joindre au sous-groupe qui débattait des dossiers qui me touchaient directement, et alors que Za m'envoyait des photos des options de laveuse et de sécheuse qui s'offraient à nous, mon ordinateur portatif est mort. Paf! Tout est devenu noir, il s'est éteint, et ne s'allumait plus. Vraiment juste au moment où j'allais présenter.

Mon groupe devant débattre principalement de propositions émanant de SG14, il était formé de Michael Wong, Billy Baker, Alan Talbot , moi-même et Howard Hinnant, de même qu'un individu dont le nom m'échappe mais qui est, je pense, le doyen ici. J'ai fini par réussir à redémarrer mon ordinateur mais, évidemment, ma préparation était à l'eau (je n'ai rien perdu outre mon organisation du travail, et il était trop tard pour me réorganiser). J'ai repris le contact avec Za mais je n'étais plus en mesure d'examiner la question des électroménagers car je devais présenter, mais j'ai confiance en elle.

Nous avons échangé pendant environ une heure trente sur divers dossiers. Je n'ai pas eu de grandes  surprises : les propositions qui me semblaient fortes ont été bien reçues et celles qui, sans être inintéressantes, me semblaient plus fragiles l'ont aussi semblé pour les autres assis à ma table.

Après une petite pause, nous avons participé aux débats publics sur plusieurs questions et pris de nombreux votes, mais quand je suis arrivé au point de défendre le dossier qui m'incombait nous approchions de l'heure du dîner. J'ai pu faire une amorce, bien reçue dans l'ensemble, et nous nous sommes séparés pour le dîner.

J'ai profité du dîner pour faire ma lessive et prendre des nouvelles de mes compagnons de CWG, dont je me suis ennuyé même si j'ai apprécié LEWG (très dynamique, très sympathique). Ça semblait être une journée classique, avec retouches et dossiers subtils (définir le sens de « progression » de manière suffisamment précise, par exemple, ou trouver une formulation qui simplifiait un passage du standard mais effaçait des heures de travail hier par exemple). J'ai eu le temps d'aller me chercher un sandwich, de mettre mes quelques vêtements à la sécheuse et de parler aux enfants (les plus jeunes, évidemment, mes plus grandes que j'adore étant plus éparpillées sur le plan géographique) avant de reprendre les travaux.

La première partie de l'après-midi fut faite de présentations et de débats en grand groupe.

Les conteneurs associatifs plats (flat_*), que je présentais et pour lesquels nous souhaitions à la fois sonder l'intérêt et obtenir des recommandations pour certaines pistes exploratoires. Ce fut un succès, j'en suis ravi.

Un tampon circulaire (fixed_ring, dynamic_ring), pour lesquels il y a un besoin mais en vertu desquels la proposition était sous-spécifiée. Il reste du travail à faire pour cela avant de revenir avec une présentation devant WG21.

L'algorithme unstable_remove() et son cousin unstable_remove_if(). J'étais partisan de cette proposition et j'ai essayé de la vendre, mais les gains étaient réels mais relativement modestes en comparaison avec au moins une alternative existante, alors LEWG a choisi de rejeter la proposition jusqu'à ce que des chiffres plus convaincants ne deviennent disponibles.

Une série d'algorithmes sur de la mémoire brute (unintialized_*()), que je voulais écrire moi-même mais qu'un collègue a écrit plus rapidement  J'était évidemment partisan de ceux-ci et j'ai pris sur moi de vendre l'intérêt. Ça a très bien été reçu et, à moins d'une surprise, ces algorithmes seront inclus dans <memory> dès C++ 17. De manière amusante, une des choses qui a facilité leur acceptation est... une erreur dans la proposition, où l'auteur n'avait pas tenu compte des risques de levée d'exceptions (probablement parce que, de par son travail dans le milieu du jeu, il est moins familier avec ces situations), ce qui a démontré à la fois le besoin pour les algorithmes (on s'en sert!) et l'importance d'offrir des implémentations standards (les versions « maison » étant subtilement incorrectes). Autre truc amusant : Howard Hinnant nous a avoué avoir délibérément omis de proposer ces algorithmes dans le passé car il pensait que personne n'en avait vraiment besoin, alors il semblait heureux de m'appuyer.

On a ensuite débattu que quelques autres trucs, dont std::hypot(x,y,z). Il existe déjà, dans <math.h> pour C et dans <cmath> pour C++, la fonction std::hypot(x,y) qui calcule . La nouvelle fonction serait <cmath> mais pas dans <math.h>, entre autres parce que C ne supporte pas la surcharge de fonctions de même nom, et calculerait . La question d'un std::hypot(args...) a été soulevée, et cela surviendra sûrement un jour (dans <numeric>, probablement), mais comme le soulignait Howard Hinnant, on peut mieux faire en restreignant à x,y,z car les spécialistes sont plus à même d'éviter des cas de débordement et de profiter du matériel sous-jacent, alors la généralisation (utilisée, mais beaucoup moins fréquemment) peut attendre.

Petite pause de milieu d'après-midi. J'en ai profité pour ramasser ma lessive, que j'ai ramené avec moi dans la salle de travail car on avait moins de dix minutes devant nous, et on s'est remis au boulot.

Alors que l'on recommençait, j'ai reçu un courriel de mon ami, collègue et technicien Robin Tremblay qui m'indiquait craindre un piratage de mon site, y voyant passer des accès FTP en direct des États-Unis. Je lui ai indiqué où j'étais et ce que je faisais, ce à quoi il m'a répondu « un jour, ce sera mon tour »... mais je ne suis pas certain qu'il ait saisi le type de voyage que nous faisons ici 

Les travaux de fin d'après-midi furent divisés en deux blocs : retoucher std::variant suite aux commentaires de LWG, et adresser divers propositions moins controversées en petits groupes.

Le retour de LWG sur std::variant était animé par Axel Naumann, auteur de la proposition, et touchait aux points suivants :

On a ensuite poursuivi en petits groupes. J'ai eu le plaisir de travailler avec Jonathan Wakely, Thomas Köppe, Alisdair Meredith et un individu dont je n'ai malheureusement pas retenu le nom. Il restait moins d'une heure alors on a pris des propositions dont la portée était circonscrite.

La proposition P0013 Logical Operator Type Traits proposait des métafonctions and_, or_ et not_ pour représenter efficacement des Fold Expressions statiques tout en ayant les bénéfices du Short-Circuit que l'on a avec les opérateurs logiques conventionnels (a&&b n'évaluera b que si a s'avère, par exemple). C'est une proposition utile mais il y a un problème de nom, du fait qu'on ne veut pas de suffixes ou de préfixes particulier dans un outil standard. On ne peut pas faire n'importe quoi non plus avec l'implémentation car ce qui est proposé est efficace en sous-tendant std::condtional_t, qui opère sur des types en général, pas nécessairement sur des std::integral_constant

La proposition P0033 Fix enable_shared_from_this est pointue. Il se trouve que enable_shared_from_this a un comportement incorrectement spécifié qui amène des fuites de ressources dans certains cas pathologiques. On se questionne sur la valeur même du concept supporté, mais bon, ça existe, et là la question est de spécifier ce qu'il faut faire. Alisdair Meredith propose que, dans le cas où l'utilisation de ce mécanisme est incorrecte, mieux vaut simplement lever une exception

La proposition P0074R0 Making std::owner_less more flexible est... obscure (je ne connaissais pas le mécanisme, et pourtant ce langage est mon principal outil de travail). La proposition couvrait un cas rare mais problématique qui survenait dans certaines situation avec un comparateur maison pour un conteneur associatif de pointeurs intelligents avec sémantique de partage.

On a fini vers 17h15. Je suis allé parler à mon épouse Za, qui me manque beaucoup, puis je me suis pris une bouchée en face (un curry avec riz brun et légumes; bon mais un peu cher) et j'ai bavardé à nouveau avec ma belle. J'ai ensuite informé Sean Middleditch, auteur de la proposition que je défendais aujourd'hui sur les conteneurs associatifs plats, du succès de l'entreprise. On a échangé par courriel sur la suite des événements, puis je suis allé à la rencontre de la soirée qui portait sur les modules.


On est une trentaine. Gabriel Dos Reis en retard de vingt minutes. Ne fera pas une démo, mais veut expliquer comment en arriver à une implémentation portable des modules. La compilation donne des métadonnées. On vise un impact sur le temps de compilation. Jason Merrill est ici, Richard Smith est ici, Jonathan Caves est ici, donc les trois principaux artisans de compilateurs sont là. Il nous manque Dawn et le représentant d'EDG.

En attendant le début des travaux, un monsieur est venu me parler. Son fils étudie en informatique ici à Hawaii mais à temps partiel, passant beaucoup de temps à jouer à des jeux.... mais étant suffisamment bon à ces jeux pour s'être bâti une communauté d'admirateurs sur les réseaux sociaux, admirateurs qui le regardent jouer, ce qui lui rapporte un salaire – maigre, comparable à celui d'un employé au salaire minimum, mais tout de même. Le papa se demandait comment l'encourager, et si c'était sain. Je lui ai recommandé d'avoir un plan B, par prudence, et je l'ai aiguillé vers Alex Rosenberg, plus près du marché que je ne le suis.

Gabriel Dos Reis imvite Richard Smith à prendre la parole. Il y a trois manières de procéder chez Clang. Un modèle explicite, qui extrait le module du code existant. Ils utilisent les #include et leur donnent le sens de import. C'est transparent, ça donne des bénéfices, mais il y a des trucs non-modulaires avec des hacks ici et là, des macros et autres. Il y a aussi un modèle explicite, où les programmeurs utilisent une syntaxe distincte. Les clients ne sont pas toujours heureux d'avoir une ségrégation des macros mais améliorent la compilation accélérée. Idéalement, on vise quelque chose de très près de ce que Gabriel Dos Reis propose, mais on souhaite un mode implicite tout de même. Le standard permet aux implémentations de donner à #include le sens souhaité par l'implémentation (il peut ne pas y avoir de fichiers sur disque pour le standard).

Gabriel Dos Reis dit que Clang a des Modules Maps, qui disent quel en-tête correspond à quel module. Chez Microsoft, ils ont choisi de ne pas utiliser de fichier de configuration, même s'ils reconnaissent la pertinence de cette approche. Ce qui est important est la capacité du code existant de bénéficier de la compilation accélérée. Les gens qui maintiennent <windows.h> sont ceux qui souhaitent le plus les bénéfices des modules, et ce sont de gros consommateurs de macros.

Gabriel Dos Reis veut, sans faire une démo, montrer ce à quoi ça ressemble, mais il compile sur un appareil Surface et ça prend un peu plus de temps que prévu. C'est un fichier qui a un #include, le mot module suivi d'un nom qui comprend un « . », et un template (un point 2D) précédé du mot clé export, et enfin une fonction main() classique. Outre module et export, c'est du code conventionnel. La compilation avec les bonnes options donne un .obj et un .ifc (interface du module; des métadonnées). Pour lier un module, il faut utiliser le .obj et une option de compilation et on génère un .obj.

Richard Smith demande comment le système gère l'ordre des dépendances des modules. Gabriel Dos Reis dit que chaque fichier source dépend de son fichier d'interface. Hors d'un module, les dépendances sont envers les fichiers d'interface, pas envers les en-têtes.

Gabriel Dos Reis dit que le système de Build est tel qu'on doit expliquer les dépendances. Richard Smith dit qu'il voit un problème ici du fait qu'on doit expliciter les dépendances, dans quel ordre, et que ça lui semble difficile à déterminer à partir des sources. Gabriel Dos Reis dit que ça dépend du système de Build. Jonathan Caves dit que leurs clients aiment que la dépendance se limite aux métadonnées. Richard Smith demande comment générer la première compilation. Jonathan Caves dit que c'est une « switch » de compilation pour transformer des en-têtes en modules. Gabriel Dos Reis rappelle que ce qu'il montre est ce qu'ils font pour le moment, de manière expérimentale, pas ce qui est proposé pour fins de standardisation. Gabriel Dos Reis dit que les .ifc sont imbriqués dans les .lib mais qu'il sait que ce n'est probablement pas ce que sera le design final.

Gabriel Dos Reis explique qu'il sait qu'il existe une dépendance entre les modules, et que cela détermine un ordre de construction; ils génèrent les .ifc à partir des en-têtes quand ils détectent une dépendance manquante. Richard Smith propose une approche utilisée chez Clang pour régler ce problème. Gabriel Dos Reis dit qu'ils ont constaté ce besoin mais ne sont pas encore rendus là dans la production.

Gabriel Dos Reis explique pourquoi ils ont choisi de placer les #include avant le module dans un fichier source; c'est bel et bien ce qu'il faisait lui aussi initialement. Ce choix est une patch : ce qui précède le mot module tient à un accès à un « module global » et ne fait pas partie du module lui-même.

Richard Smith critique ce choix; pour déduire les interdépendances entre les modules, il apprécierait voir le mot module tout en haut du fichier. Gabriel Dos Reis le remercie d'apporter un commentaire aussi concret, et indique que son implémentation ne se veut que transitionnelle.

Daveed Vandevoorde parle d'une implémentation antérieure du même concept. Gabriel Dos Reis dit avoir étudié cette implémentation mais avoir fait un autre choix dans une optique de simplicité. Gabriel Dos Reis parle des inline import mais je n'ai pas saisi les nuances de l'argumentaire. Richard Smith suggère englober les #include par un inline import et placer module tout en haut. Gabriel Dos Reis recommande d'apporter une proposition, ce que Richard Smith dit qu'il fera.

Jonathan Caves indique que tout ce qui apparaît ici est pragmatique : les parties « hors du contrôle des programmeuses et des programmeurs » vont en haut du mot module, puis ce qui est contrôlé suit. Leur approche est User-Driven. Richard Smith critique la difficulté de généraliser cette approche. Jason Merrill dit comprendre que de part et d'autres, il y a des systèmes hérités et des approches transitionnelles distinctes. Richard Smith se dit d'avis que les approches transitionnelles devraient être hors du langage. Jonathan Caves dit être d'accord. Gabriel Dos Reis défend son choix d'y aller avec #include, puis import, puis module sur la base de la rétroaction des usagers... Daveed Vandevoorde revient avec l'argumentaire de la vitesse de traitement de fichier en plaçant module tout en haut.

Gabriel Dos Reis demande aux gens à quel point avoir plusieurs fichiers à traiter pour que le compilateur comprenne les dépendances les irrite. Alex Rosenberg dit que c'est un irritant dans son entreprise, pour les clients et pour les outils. Gabriel Dos Reis demande si ce serait encore un irritant si Windows facilitait la vie des clients. Gabriel Dos Reis indique que MSBuild sera évidemment mis à jour pour les modules. Alex Rosenberg explique l'ampleur du problème en fonction du nombre de projets et de fichiers à traiter chez Sony. Jonathan Caves demande si l'option de compilation pour imbriquer l'information de débogage dans les .obj est utile. Alex Rosenberg dit que les gens utilisent Visual Studio est les outils qui l'accompagnent, mais dit ne pas connaître cette option qui inclurait les métadonnées à même les .obj. Alex Rosenberg admet que ça aidera, mais ne peut attester que ce sera suffisant.

Gabriel Dos Reis demande si la génération d'un fichier de métadonnées par la compilation d'un module est quelque chose avec lequel nous sommes confortables. Alex Rosenberg dit ne pas avoir une compréhension suffisamment fine de ce que MSVC fera concrètement. Arthur O'Dwyer explique sa compréhension et indique qu'avoir un seul fichier est évidemment (selon lui) mieux que d'en avoir deux. Gabriel Dos Reis n'est pas convaincu; Arthur O'Dwyer demande l'argumentaire.

Richard Smith explique l'approche de Clang. Pour les modules implicites, le compilateur tient à jour une cache des modules par identifiant. Pour les modules explicites, un outil à la ligne de commande génère les modules et leurs dépendances à partir d'options à la ligne de commande. Gabriel Dos Reis demande comment et pourquoi le passage du modèle implicite au modèle explicite s'est fait. Richard Smith explique que sur un même poste, le modèle implicite fait bien le travail, mais pour fins de distribution et à grande échelle, l'approche explicite marche mieux. Gabriel Dos Reis trace un lien avec son approche; à son avis, une fois passé le cap de la syntaxe, les deux approches sont très semblables, et pour des raisons aussi fort similaires.

Hubert Tong demande si on examine une approche d'édition des liens plus intelligente. Jonathan Caves dit oui, mais c'est loooong. Jason Merrill dit qu'il est trop tard en pratique dans le processus de compilation pour en profiter. Gabriel Dos Reis nuances (il y a des points où on peut en profiter). Jason Merrill explique sa vision de ce qui se passe et, sans le dire, Gabriel Dos Reis semble d'accord avec sa lecture.

Daveed Vandevoorde parle des en-têtes, qui sont un format portable, et se questionne sur l'interopérabilité. Il mentionne aussi les outils Lint et leur futur. Gabriel Dos Reis dit que le format de MSVC sera à code ouvert en totalité, incluant la description du format et une API pour celles et ceux qui voudront interfacer avec. Gabriel Dos Reis dit avoir documenté le format .ifc avant de passer à l'enseignement, il y a plus de dix ans, en travaillant avec Bjarne Stroustrup et sur la base de gcc, puis Andrew Sutton a travaillé avec eux avant d'utiliser Clang. Gabriel Dos Reis relate des échanges avec Douglas Gregor lors des travaux initiaux sur les concepts et explique que Douglas Gregor se plaignait des temps de compilation; à cette époque, ils avaient partagé le format .ifc.

Alex Rosenberg se dit certain qu'on finira par haïr le format .ifc et demande des détails. Gabriel Dos Reis dit que ça comprend les portées, les types, les paramètres par défaut, la déclaration des classes, les membres de classe, une représentation des fonctions constexpr, un AST des templates exportés. Il demande à Richard Smith ce que Clang pose dans ces fichiers; Richard Smith dit « tout ». Clang utilise un format lossless à toutes fins pratiques. Gabriel Dos Reis dit ne conserver que ce qui est sémantiquement pertinent pour les interfaces.

Jason Merrill demande si les sources apparaissent dans les .ifc, ce qui permettrait aux compilateurs de générer le code comme ils le souhaitent. Richard Smith dit comprendre que les modules ne sont pas un format de distribution. Jason Merrill dit que le standard ne discute pas de distribution, mais que le code source de C++ est un bon format pour fins de distribution; selon lui, les modules sont construits sur la base du code source après tout. Gabriel Dos Reis dit comprendre que le .ifc contient le fruit de la compilation des modules, et que la capacité de consommer ces fichiers devrait être suffisant. Les .ifc ne remplacent pas les en-têtes, et selon Gabriel Dos Reis il est plus facile de traiter un .ifc que des sources C++.

Daveed Vandevoorde dit comprendre que les modules ne montrent plus clairement une distinction entre l'interface et l'implémentation, mais on ne veut pas nécessairement distribuer l'implémentation. Comment s'en sortir? Gabriel Dos Reis dit que le .ifc permet de regénérer les en-têtes. Richard Smith dit que chez Clang, on a fait le constat que les modules ne fonctionnent pas en termes de format de distribution, étant assujettis à des trucs comme support des exceptions, niveaux d'optimisation et autres. Gabriel Dos Reis dit qu'il estime qu'il soit concevable de distribuer des .ifc mais que ce n'est pas l'intention derrière ce format. Richard Smith dit qu'une API portable pour les AST est essentielle; Gabriel Dos Reis est d'accord pour faciliter la tâche des outils.

Michael Spencer demande comment générer des diagnostics de qualité sur la base du contenu des .ifc si ces fichiers se limitent aux graphes sémantiques. Jonathan Caves indique que les .ifc contiennent des informations sur les lignes des sources originales, de même que des hash ce qui permet de retrouver les points clés des fichiers sources.

Alex Rosenberg estime que standardiser les .ifc est une bonne idée, car certains clients vont vouloir les utiliser pour fins de distribution ou d'obfuscation. Gabriel Dos Reis dit que ce n'est pas l'intention. Alex Rosenberg insiste qu'à son avis, ce format sera propriétaire, servira pour fins de sérialisation et sera brisé par C++ 20 et plus. Gabriel Dos Reis dit que présentement, les compilateurs écrivent le fruit de leur compilation sur disque. Le format .ifc serait idéalement à code ouvert selon lui. Alex Rosenberg dit que Richard Stallman a dit Over my Dead Body, mais Jason Merrill dit qu'il a donné du lousse là-dessus, et que gcc a du Link-Time Optimization maintenant.

Gabriel Dos Reis dit qu'une des raisons pour lesquelles il aimerait que les .ifc soient à code ouvert est précisément pour éliminer ces craintes. Jason Merrill ne pense pas que débattre des mérites des .ifc n'apporte quoi que ce soit ce soir. Gabriel Dos Reis est d'accord et s'excuse. Hubert Tong indique qu'il y aura inévitablement des formats compétiteurs ici. Gabriel Dos Reis rappelle souhaiter l'ouverture des formats. Jason Merrill dit comprendre que la proposition distingue une unité d'interface et une unité d'implémentation, et que les interfaces seraient publiées.

Richard Smith indique qu'il est toujours possible de gérer les interfaces comme on le fait déjà; refaire les erreurs de Java et de C# en plaçant tout au même endroit est quelque chose que l'on souhaite éviter en C++. Daveed Vandevoorde demande à Richard Smith comment Clang procède pour la séparation de l'interface et de l'implémentation; Richard Smith dit qu'on utilise pour le moment les .cpp et les .h mais qu'on pourrait en arrive à de nouveaux noms de fichiers.

Michael Spencer soulève la question des violations d'ODR, en particulier dans le cas où deux compilateurs procéderaient différemment. Jason Caves dit qu'on devra être plus prudents. Jason Merrill estime qu'on risque d'en avoir moins, en pratique.

Un individu dont je connais pas le nom prend le micro et dit vouloir parle de Packet Manager, et demande si un format intermédiaire (pas d'inclusions, rapide à compiler) pour le livrer dans un gros .cpp simplifié pour fins de compilation sur diverses plateformes serait envisageable. Gabriel Dos Reis dit que ce sujet est très complexe, et qu'il ne l'adresse pas avec les modules; les fichiers .ifc ne sont pas un format pour livrer des sources.

Richard Smith dit qu'à son avis, la question du Packaging est hors de la portée des modules. Il se demande par contre comment on arrivera à des noms de modules suffisamment uniques; il n'a pas de solution à ce problème pour le moment. Gabriel Dos Reis dit aimer ce type de rétroaction, mais pense qu'on a plus de peur que de mal pour le moment. Gabriel Dos Reis se dit heureux de la rencontre de ce soir et se dit solidaire de la communauté à code ouvert; il ne propose pas les .ifc comme partie des modules pour fins de standardisation, mais compte écrire des articles pour expliquer son format pour les intéressé(e)s. Il dit qu'il est clair à ses yeux que chaque compilateur ait son propre format. Alex Rosenberg ddit que pour lui, c'est l'API qui compte le plus, plus que le format .ifc en tant que tel. Gabriel Dos Reis dit que l'API est déjà prête pour publication, et qu'il ne reste qu'à appuyer sur un bouton (c'est déjà approuvé par le Management). Michael Spencer demande si c'est le même code que celui utilisé par cl.exe, et Gabriel Dos Reis dit « oui ».

Hubert Tong demande si on sait comment le contrôle des versions sera inclus dans les modules, et se dit d'avis que ce serait un excellent moment pour se débarrasser de l'Argument-Dependent Lookup. Richard Smith dit que les modules règlent le problème qu'ils doivent régler, point. Hubert Tong décrit son point se de vue sur le sujet. Richard Smith dit qu'on est loin d'un système de contrôle des versions. Jonathan Caves dit que c'est un bon premier pas dans la bonne direction, pas la fin du chemin.

Gabriel Dos Reis remercie Alex Rosenberg pour avoir exprimé ses préoccupations, et dit souhaiter arriver à le rassurer. Alex Rosenberg dit avoir besoin de comprendre les liens entre les modules, les .DLL et d'autres entités importantes. Gabriel Dos Reis dit aimer cette question, et va oeuvrer pour adresser cette documentation; il est clair que c'est d'intérêt public.

Je bavarde un peu avec Alex Rosenberg avant de quitter. C'est un chic type avec des préoccupations concrètes, qui craint beaucoup les « pelleteux de nuages »; je ne sais pas s'il commence à être rassuré mais on peut l'espérer.

J'ai ensuite pris un peu de temps pour relater ma journée, et je suis allé me coucher car demain matin, je dois présenter la proposition de Karl-Étienne Perron devant EWG, le « gros groupe » sur l'évolution du langage. Ça ne passera pas tel quel (il a fait du bon travail, excellent considérant que c'est sa première proposition à vie, mais c'est pas prêt; c'est pas sa faute, car le sujet est subtil, mais ce qu'il a fait vaut la peine d'être présenté et débattu). La rétroaction du groupe guidera la suite des événements, alors mon objectif sera double : intéresser le groupe suffisamment pour qu'il y ait un intérêt envers la suite des événements, et obtenir des pistes pour poursuivre les travaux.

Jour 5 23 octobre 2015

Au lever, je fais le tour des nouvelles, je prends une douche et je me mets au boulot en vue de ma présentation de ce matin. Mon petit groupe, CWG, me manque un peu mais ce sera un matin d'EWG, et le vendredi après-midi est normalement une plénière où nous revenons collectivement sur les décisions prises dans les divers groupes de travail toute la semaine durant.

Travailler dans d'autres groupes cette semaine a été enrichissant, mais je suis moins au fait de ce que CWG présentera tantôt, ayant manqué le jeudi tout entier, et risquant fort de manquer ce matin aussi. Y a rien de parfait.

J'ai passé les premières heures de la journée à fignoler de mon mieux la présentation que je dois faire. Walter E. Brown m'a informé par courriel qu'il ne peut garantir sa présence ce matin; ma présentation devait être la première du jour, mais je suis le quatrième dû à des retards encourus hier chez EWG, ce qui lui cause un conflit d'horaire. Il faut comprendre que je présenterai ce matin une proposition de Karl-Étienne Perron, un de mes étudiants en IFT630 à l'été 2015, et que cet étudiant a assuré la suite d'une proposition de Walter E. Brown qui l'a co-accompagné avec moi. Walter E. Brown est un très gentil monsieur, qui a agi avec beaucoup de respect et de considération pour Karl-Étienne Perron (pour qui il s'agit d'une première expérience du genre). Walter E. Brown m'a donné son numéro de téléphone cellulaire pour que je l'informe quand mon tour approchera, mais je ne peux malheureusement pas l'appeler (je n'ai pas le genre d'équipement requis pour ce faire) alors je vais essayer de le rejoindre autrement.

L'ordre du jour de ce matin est bien rempli.

Remaining design issues for Coroutines

Les coroutines sont un des gros sujets de la semaine. Gor Nishanov présente. Il y a une demande pour ajouter await_transform aux coroutines. Cela réduirait les risques d'erreurs dans certaines circonstances. Cela donnera aussi un point d'ancrage pour fins de suivi, de profilage, de débogage, etc. et allégera l'écriture formelle dans le standard.

Bjarne Stroustrup demande si ceci aura un coût à l'exécution. Gor Nishanov dit absolument pas; c'est purement notionnel. Ce sera un Breaking Change par contre, alors mieux vaut l'adopter tout de suite si on le veut; sans cela, co_return sera toujours return; et co_return val; sera toujours return val;. Les détails de ce que l'on fera avec seront cachés dans le code de la bibliothèque.

P0135R0 Guaranteed copy elision through simplified value categories (Richard Smith)

Richard Smith est sur la scène. Il est d'avis que sa proposition simplifiera la vie de bien des programmeuses et des programmeurs. Il explique Copy Elision, qui est une suggestion dans le standard actuel : tu crées un objet, tu le copies ailleurs, on aurait pu éviter l'objet intermédiaire. Ça fonctionne, mais (a) c'est une suggestion, pas une obligation, et (b) on aurait parfois pu faire un mouvement au lieu d'une copie.

Richard Smith présente le texte actuel du standard qui liste les cas potentiels d'élision. En gros, c'est tous les cas d'initialisation d'un objet par valeur à partir d'une temporaire. Il parle de RVO, bien sûr. Il y a aussi le cas où un compilateur peut, par analyse, déterminer qu'un objet est copié à partir d'un autre qui a vécu mais n'a jamais été modifié.

Richard Smith parle de l'intérêt de rendre Copy Elision obligatoire. On sait tous que ce mécanisme fonctionne bien sur tous les compilateurs contemporains, mais on oblige quand même les programmeuses et les programmeurs à coder des constructeurs de copie et de mouvement même s'ils ne seront jamais utilisés. Enfin, s'il restait des compilateurs qui ne font pas cette optimisation, ils seraient enfin contraints à générer du meilleur code, mais Richard Smith avoue ne pas en connaître qui négligent de poser ce geste.

Richard Smith mentionne ensuite que le fait que c'est presque toujours fait est un gros irritant : nous programmons sur la base d'attentes que nous avons envers nos compilateurs, mais nous devons en même temps nous défendre, en quelque sorte, contre des implémentations suboptimales.

Enfin, Richard Smith indique que Copy Elision est actuellement l'une des 2-3 particularités de C++ qui n'est pas clairement garantie mais a un impact observable sur le comportement des programmes.

Richard Smith montre ensuite l'impact d'une Copy Elision obligatoire sur le code, et explique en quoi cela allègerait la tâche des compilateurs.

Pour y arriver, Richard Smith propose de modifier le texte normatif décrivant ce que sont les catégories de valeurs (xvalue, prvalue, lvalue, glvalue, rvalue). Ce tronçon du standard est très complexe et ardu à expliquer. Il suggère de grouper comme suit :

glvalue :: environnement → (environnement,lieu)
prvalue :: (environnement,lieu) → environnement

Ville Voutilainen demande une précision, que Richard Smith donne, mais c'est très rapide et je n'ai pas le temps de les noter. Richard Smith dit que ce glissement n'affecte pas les catégorisations existantes des expressions, mais simplifie le modèle mental de ce que nous faisons en pratique. Richard Smith discute ensuite des impacts de ce changement avec des exemples.

David Sankel demande une précision sur les xvalue, qui sont selon Richard Smith une sorte de glvalue. Richard Smith dit qu'on pourrait maintenant mieux parler des objets temporaires, et qu'on peut mieux cerner les cas où Copy Elision s'applique. Son écriture unifie aussi les classes et les primitifs de manière plus homogène.

Ville Voutilainen demande en quoi ceci impactera les implémentations existantes. Richard Smith répond que les changements seront minimaux pour celles où Copy Elision est déjà appliquée. Certains cas de SFINAE peuvent être affectés aussi. Cela dit, la proposition correspond à ce que certains compilateurs font déjà. Bjarne Stroustrup trouve heureux que nous en arrivions enfin à offrir de meilleures garanties à la compilation, qui réduiront les avertissements et les erreurs à la compilation. Bjarne Stroustrup se dit aussi d'avis que les gens sont capables de mal comprendre n'importe quoi, donc qu'on ne doit pas s'empêcher d'avancer pour cela. Ville Voutilainen apprécie qu'on pourra écrire de meilleures fabriques. Chandler Carruth signale qu'on rend quelque chose de complexe un peu moins complexe.

Les alternatives sont proposées :

Ville Voutilainen prend le vote. C'est très fortement favorable. Ça sera dans C++ 17 si la formulation est Ok selon CWG.

P0128R0 constexpr_if (Ville Voutilainen)

C'est un suivi d'une proposition faite à Lenexa, qui viserait une facilité analogue à celle de static_if en D, mais limité à une portée. Ville Voutilainen explique comment on en arrive actuellement à choisir entre deux blocs de code à la compilation, par exemple pour faciliter le choix de pratiques de compilation sur la base de ce qu'un compilateur particulier implémente (ou non).

Ville Voutilainen explique que le recours à des λ en remplacement d'un tel mécanisme ne permettrait pas d'avoir recours à l'ensemble des mécanismes de contrôle de l'exécution (return, break ou autre). Le code permis par constexpr_if remplacerait essentiellement de multiples instanciations d'un template primaire, et simplifierait à la fois l'écriture de programmes et l'enseignement selon lui.

Ville Voutilainen indique que cette facilité n'est pas banale à implémenter mais qu'il existe un prototype de quelque chose de très près.

David Sankel demande si constexpr_also a été considéré. Ville Voutilainen dit non, et indique ne pas avoir considéré constexpr_else ou constexpr_else_if pour que le tout reste gérable.

Bjarne Stroustrup parle des impacts de l'ajout de noexcept dans le système de types sur de tels mécanismes, ce qui peut dupliquer la quantité de travail à faire dans ces circonstances. Il estime que les deux directions entrent en conflit. Ville Voutilainen pense que les surcharges nous mènent déjà là. Bjarne Stroustrup dit que les modules noexcept sont viraux.

Quelqu'un dit avoir lu que les concepts seraient une option supérieure à constexpr_if dans la proposition. Andrew Sutton indique que les concepts contraignent les déclarations, sans plus. Ville Voutilainen montre la section visée dans la proposition et montre qu'il faut tout de même écrire plusieurs surcharges. Quelqu'un dit craindre constexpr_switch, constexpr_for... Ville Voutilainen dit qu'on ne verra pas une telle proposition émanant de lui, mais ne peut garantir ce que d'autres individus pourraient faire.

Ville Voutilainen prend le vote. C'est une question qui divise mais qui revient périodiquement. Je suis personnellement neutre, même si je vois les avantages (ça me semble semi-idiomatique), mais c'est favorable alors ça s'en va chez CWG.

P0078R0 The [[pure]] attribute (Karl-Étienne Perron; Patrice Roy to present)

Je n'ai pas pris de notes étant donné que j'étais sur la scène, mais en gros :

Je pense qu'il y a de l'intérêt pour ces travaux. J'ai envoyé un rapport détaille à Karl-Étienne Perron et de Walter E. Brown par la suite; j'ai aussi eu quelques conversations privées avec des gens, et pas les moindres, qui ont montré un intérêt direct pour ce qui est proposé et qui souhaitent voir les divers efforts converger.

P0120R0 constexpr unions and common initial sequences (Anthony Williams, presented by Roger Orr)

Roger Orr explique qu'Anthony Williams a travaillé avec des union comportant des Common Initial Sequences, et s'est trouvé coincé dans l'écriture des règles sur constexpr dans ces circonstances du fait que le moment de l'évaluation n'est pas le même.

Selon Daveed Vandevoorde, si nous modifions l'écriture normative pour permettre l'accès aux Common Initial Sequences dans un contexte constexpr pourrait ralentir significativement la compilation. Roger Orr présente le changement normatif et explique que la consommation d'espace mémoire pourrait être réduite de manière intéressante ici.

Beaucoup de gens sont neutres. Les pour et les contre sont partagés de manière à peu près égale. Pas de consensus.

P0127R0 Declaring non-type template arguments with auto (James Touton)

James Touton présente son texte comme template<auto>. Son exemple est du Function Logging. Je n'ai pas tout pris en note car j'écrivais à Karl-Étienne Perron pour lui donner une rétroaction sur le traitement donné à sa proposition.

James Touton dit avoir implémenté son idée avec Clang et avoir des résultats intéressants pour générer des listes de valeurs hétérogènes. Il permet une syntaxe comme template<auto... Ts> pour hétérogénéité et template<auto T, decltype(a)...Ts> pour homogénéité.

Walter E. Brown demande comment cette proposition interagirait avec les concepts. James Touton dit que sa proposition n'adresse pas cette question.

Daveed Vandevoorde demande ce qui se passe avec les spécialisations partielles.  James Touton explique.

Il y a beaucoup de réactions positives dans la salle. C'est précis, ciblé et utile.

Walter E. Brown se dit en faveur dû à la présentation (il était plus froid sur la base du texte). Il rappelle toutefois que dans le monde des concepts, le mot auto prend le sens du concept satisfait pour tous les types. Il se demande conséquemment comment cette proposition interagirait avec les concepts étant donné cette sémantique émergente. Andrew Sutton, qui est dans le coin, explique qu'il y aurait des conséquences : il est possible d'utiliser un nom de concept là où on utilise auto, car auto est un concept, ce qui entraîne une ambiguïté dans l'écriture auto T sur la nature de T.

Gabriel Dos Reis dit qu'il faut distinguer le choix du mot auto en tant que Placeholder et l'idée générale présentée par James Touton, et pour cette raison ne voit pas de conflit. Quelqu'un demande ce qu'il se passera si on passe 5 au Function Logger, et prédit que ça donnera des messages d'erreur très laids; il préférerait qu'on puisse contraindre ce mécanisme avec des concepts.

Bjarne Stroustrup pense que la proposition devrait être ajoutée au TS sur les concepts. Gabriel Dos Reis est d'accord. James Touton dit que cela rattacherait sa proposition à celle des concepts, et est craintif. Gabriel Dos Reis dit aimer la proposition et vouloir y contribuer. Bjarne Stroustrup dit avoir vu des idées semblables dans le passé, c'est pas si nouveau est c'est vraiment désiré. Quelqu'un ajoute qu'il veut beaucoup ce mécanisme, mais soutenu par les concepts, et est disposé à attendre si c'est ce qu'il faut.

Botond Ballo parle de l'interaction du mécanisme avec des paramètres non-types et voit des ambiguïtés. James Touton demande si les concepts peuvent résoudre le problème. Andrew Sutton pense que oui.

Chandler Carruth fait un lien avec std::tuple, qui combine à la fois types et non-types, et se dit d'avis que ce genre de problème demeurera difficile.

On demande un vote pour l'inclusion de cette proposition aux concepts. Andrew Sutton se dit intéressé à contribuer. Walter E. Brown se dit heureux de savoir qu'il existe une implémentation dans Clang mais exprime qu'il préférerait le voit dans gcc 6.0+ qui inclut déjà les concepts. Le vote est clairement positif.

P0091R0 Template parameter deduction for constructors (Rev. 3) (Mike Spertus, Richard Smith)

Mike Spertus montre la bouette que l'on doit écrire dans certains cas, comme lorsqu'on écrit lock_guard<shared_mutex> lck{...}. Un make_lock_guard() poserait problème car lock_guard n'est pas déplaçable. Il montre que les fonctions génératrices ne suffisent pas en ajoutant l'exemple de make_reverse_iterator() qui n'apporte essentiellement rien. Il n'existe pas de make_unique_lock(), à titre d'exemple, alors même dans le meilleur des mondes, on doit écrire plusieurs petites fonctions seulement pour se faciliter l'existence.

Mike Spertus avoue écrire du Java presque 80 heures par semaine ces jours-ci et constater à quel point ce langage nous force à écrire du texte redondant, du Boilerplate. Cela l'a motivé à proposer un allègement syntaxique pour C++ dans les cas où les deux langages se ressemblent trop.

Nos fonctions ne sont pas homogènes : make_tuple(), back_inserter(), etc. Selon Mike Spertus, cette écriture redondante accroît la difficulté d'accès initial au langage (Barrier to Entry).

Mike Spertus propose de permettre des trucs comme :

auto p = pair(2,3.5);

...plutôt que le statu quo qui est :

auto p = pair<int,double{2,3.5};

Sa proposition vise à spécifier le sens de « être déductible », de manière à synthétiser les fonctions de fabrication à partir d'une syntaxe de constructeur. On aurait une écriture canonique et le code serait plus direct.

Évidemment, il indique qu'avec ceci :

list<int> lst { 2,3,5,7,11 };
auto v = vector(begin(lst), end(lst));

... ne pourra fonctionner sans un peu d'aide (ça passerait par une inspection des traits des itérateurs). Mike Spertus présente la notation réfléchie par Richard Smith pour synthétiser cette fabrique canonique et même qu'une autre de son propre cru. Mike Spertus se dit d'avis qu'on n'aurait pas à implémenter la fabrique; une déclaration suffirait pour synthétiser le code de fabrication.

On demande pourquoi la déclaration de la fabrique n'est pas dans la classe. Mike Spertus indique que cela pourrait poser problème dû à une confusion des types des paramètres. Richard Smith explique son point de vue pour la syntaxe qu'il met de l'avant, et qui semble bien reçue; en gros, il craint de confondre les gens de par une syntaxe trop différente de celle des fonctions. Bjarne Stroustrup propose une syntaxe charmante pour alléger l'écriture (ajouter =default quelque part pour indiquer que c'est ce qu'on veut). Quelqu'un fait remarquer qu'on est très près ici des alias sur des fonctions, souvent demandées mais pas dans le langage, mais Mike Spertus dit ne pas y avoir réfléchi. Richard Smith fait un lien avec using, mais indique une nuance sémantique qu'il estime suffisante pour ne pas franchir ce pas.

Daveed Vandevoorde critique l'une des deux syntaxes. Chandler Carruth dit ne pas comprendre comment on pourrait implémenter la déclaration-synthétisant-une-définition, puisque la « déclaration » n'introduit rien; c'est une mise en correspondance de types (une Type Map), plus une définition implicite qu'une déclaration. Bjarne Stroustrup semble d'accord.

Richard Smith trace une distinction entre leur approche et les fonctions génératrices, au sens où leur approche sauve systématiquement une copie. Walter E. Brown propose de scinder la proposition en deux, pour que la notation la moins controversée passe tout de suite et que les travaux se poursuivent sur l'autre.

Richard Smith se dit préoccupé par la partie de la proposition qui introduit une nouvelle considération dans la déduction des paramètres des templates, et craint que l'on ne génère des faux-positifs. Mike Spertus indique que le cas le moins controversé est plutôt conservateur et semble moins risqué à court terme. Une autre risque avec l'approche plus novatrice / plus risquée à ce stade est l'injection de noms de types.

Richard Smith parle ensuite de la stabilité des interfaces suite à l'adoption d'un tel mécanisme. Certaines pratiques existantes dans les implémentations des bibliothèques standards seraient sujettes à être retouchées. Mike Spertus relate que la proposition, sous une forme antérieure, a été acceptée par EWG, envoyée à CWG qui a attrapé le problème et a retourné la proposition à ses auteurs. Mike Spertus indique qu'aucun programme C++ 14 conforme ne serait brisé, mais que certaines déclarations de classes pourraient être légèrement différentes en mettant ce nouveau mécanisme en application.

On demande quoi faire quand une classe a un constructeur qui prend un const T& et un autre qui prend un T&&. Richard Smith explique les règles.

C'est très favorablement reçu dans l'ensemble, même s'il y a des opposants. Les deux propositions ont un support de l'audience. Chandler Carruth dit qu'il aimerait deux propositions distinctes, pour qu'au moins une des deux survive quoi qu'il arrive; Mike Spertus se dit d'avis que l'une dépend de l'autre. Une proposition plus formelle suivra à la prochaine rencontre.

D'autres dossiers étaient à l'ordre du jour mais nous n'avons pas eu le temps de les traiter, et je crois comprendre que les auteurs des propositions n'étaient pas présents ici.

Après la rencontre d'EWG, je m'en allais travailler un peu quand je suis tombé sur le sympathique Aurélien Regat-Barrel, de http://cpp-lang.io/ qui fait des entrevues ici pour les trente ans du langage. Nous en avons profité pour parler français un peu (toujours agréable quand c'est possible) et nous sommes allés manger une bouchée (de la bouffe végé et, dans son cas, sans gluten; je me suis pris un sandwich portobello, zucchini et avocats avec un smoothie à la mangue). Ce fut bien agréable.

Au retour, Aurélien Regat-Barrel est allé mener ses entrevues et je me suis installé pour la plénière. Sur la base de mes souvenirs de Lenexa, je m'attends à un après-midi politiquement fort intéressant. J'ai aussi pris un moment pour voir si je pourrais garder ma chambre quelques heures de plus demain, pour être en mesure de prendre une douche avant de quitter, mais ce ne sera pas possible; par contre, l'hôtel a ce qu'on y appelle une « chambre de courtoisie », prêtée une heure à la fois sans frais, pour des gens dans ma situation. Elle était prise de 16h à 17h alors je leur ai demandé de me la réserver de 15h à 16h. Ça ne fera pas de moi quelqu'un de plus présentable une fois de retour à la maison, mais je serai sûrement moins déplaisant pour mes voisins dans l'avion lors des diverses étapes de mon retour.

Clark Nelson prend la parole. Walter E. Brown propose qu'on remercie publiquement nos hôtes. On les applaudit.

On accueille les rapports des groupes d'étude :

SG5 (mémoire transactionnelle, Michael Wong) : le PDTS est complet et sur le site d'ISO. Le groupe d'études travaille sur les suites. Les télérencontres ont lieu aux deux semaines environ. On étudie les interactions avec les coroutines

SG6 (numériques, Lawrence Crowl) : nous avons passé en revue trois propositions et acheminé deux. Nous envisageons une spécification technique. Des alias, un type décimal, de l'arithmétique détectant les débordements, de l'arithmétique multiprécision, des opérations bit à bit, arrondissement et débordements. Le prochain gros sujets est les gros entiers signés, un truc proche des entiers non-signés, et on envisage des nombres à virgule flottante sans limites de même qu'un type rationnel. Des types avec plages maison sont envisagés. Les conversions envisagées sont toutes explicites.

SG7 (réflexivité, Chandler Carruth) : discussions informelles seulement cette fois. On vise Jacskonville ou Oulu. Herb Sutter demande si SG7 a une échéance en tête. Chandler Carruth dit que plusieurs propositions ont émergé de SG7, la plupart sont des propositions de bibliothèques. Ils sont un peu bloqués sur le coeur de l'introspection

SG12 (comportement indéfini, Gabriel Dos Reis) : une rencontre s'est tenue hier. On examine entre autres comment faire en sorte que le fruit d'un memcpy() d'un objet puisse être un objet, ce que le standard ne permet pas présentement. La situation est similaire suivant une sérialisation. CWG travaille sur la définition d'objet; Richard Smith a une définition prometteuse.

Il y a une réaction très, très forte de membres de SG1 dans le fond de la salle sur ce qui est memcpy()-able. Gabriel Dos Reis n'est pas sûr de ce qui se passe. Jason Merrill lance « Core en a parlé, on est en train de résoudre le problème ». La salle applaudit. Gabriel Dos Reis est perplexe, n'ayant pas compris ce qui s'est passé.

SG14 (low latency, Michael Wong) : nous avions huit propositions, la plupart pour LEWG. Certaines avancent, d'autres retournent vers leurs auteurs, ce qui est très bien. Nous avons aussi tenu une séance de travail mercredi soir. Nous tenons des télérencontres chaque mois. Michael Wong liste les sujets d'intérêt et met de l'avant qu'ils recoupent ceux d'autres groupes. Du travail a été fait avec Gor Nishanov pour les coroutines. Herb Sutter relate l'historique de ce groupe de travail t fait remarquer la beauté de la dynamique organique mise de l'avant par Michael Wong.

SG1 (concurrency and parallelism, Hans Boehm) : on a plusieurs TS. Certains sont déjà livrés. Nous avons un nouveau TS qui s'annonce; le premier jet avait un aspect controversé avec atomic_compare_exchange(), donc vous verrez un changement. Il y a une subtilité aussi avec les pointeurs intelligents. Nous avons au passage trouvé des bogues dans le standard C++ 14 que nous visons à corriger. Nous avons des latches, des barriers, des pointeurs intelligents atomiques et des raffinements aux futures. Nous avons aussi commencé à travailler sur les TS2 du parallélisme, qui pourrait inclure les Task Blocks. Je m'attends aussi à un raffinement terminologique pour les agents d'exécution et les garanties de progression. Nous visons aussi un Concurrency TS2, qui contiendrait probablement les exécuteurs, mais c'est moins avancé. On voit apparaître des types synchroniques, des atomic_views pour opérer de manière atomique sur des non-atomiques. S'ajoutent à tout cela des éléments mineurs : prendre le TS de parallélisme original et l'intégrer à C++ 17 (ce sera peut-être fait à Jacksonville); quelques ajustements au texte existant pour réduire les dépendances envers ce qui est thread_local. Nous avons discuté de GPU, et avons déterminé que nous ne voulons pas un C++ restreint pour les GPU (nous visons une autre approche).

Nicolai M. Josuttis demande ce qui sera dans C++ 17. Hans Boehm parle d'une liste de petits éléments, mais dit que la discussion n'est pas complétée.

On discutera de SG10, Feature Test Macros, à la toute fin.

On aborde ensuite les groupes de travail.

EWG (Ville Voutilainen) : nous avons traité presque toutes les propositions. Les modules s'en vont vers un TS, entre autres. Tristement, nous avons manqué de temps pour quelques propositions et les Evolution Issues n'ont pas été traitées, faute de temps. Nous avons enfin variant, suivant la rencontre de soirée. Une dizaine de propositions ont été acceptées par EWG, dont les variables inline et les lambda constexpr. La proposition pour garantir Copy Elision et le constexpr_if sont acceptés. On fait quelques blagues sur le fait que CppCon 2015 a ralenti certains travaux, mais Bjarne Stroustrup souligne que CppCon 2015 a aussi permis aux gens de discuter informellement hors-comité. Nicolai M. Josuttis demande si les concepts seront dans C++ 17; Herb Sutter dit qu'il y aura une proposition et ce sens, et on verra.

LWEG (Jeffrey Yasskin) : nous avons couvert près de quarantre propositions, en avons rejeté huit, accepté une quinzaine, et avons demandé aux autres de continuer à réfléchir. Nous pensons avoir couvert les propositions les plus importantes du lot.

CWG (Mike Miller) : ma présentation est en format PDF sur le Wiki de CWG. Nous avons un peu changé nos pratiques. Il y a plus de propositions qu'auparavant, alors nous ne publions plus la liste complète des Core Issues. Une version publique est disponible sur le site public de WG21. Les dossiers traités lors de téléconférences sont placées à part pour être examinées en plus grand groupe. Lors de cette rencontre-ci, il y avait deux grands thèmes : les Open Issues, dont nous avons traité 15 cas qui seront mises de l'avant à Jacksonville; 59 nouveaux dossiers, dont nous avons traité environ la moitié (nous poursuivrons demain); et les dossiers qui nous ont été relayés par d'autres groupes. Les dossiers que nous mettront de l'avant incluent supprimer le mot clé register (qui demeure réservé), retirer operator++(bool), intégrer les spécifications d'exceptions dans le système de types (Nicolai M. Josuttis demande si ça brise du code existant, Jens Maurer dit oui, Ville Voulitainen dit que c'est des cas très obscurs; Jeffrey Yasskin demande si l'ajout de noexcept à la bibliothèque standard brisera du code, et Ville Voutilainen dit non; Lawrence Crowl cite un cas qui serait brisé pour la portabilité de compilateur à compilateur; Bjarne Stroustrup se dit confiant qu'il y aura des problèmes avec ceci mais ne parvient pas à clarifier lesquelles; Chandler Carruth dit qu'il devient plus facile avec ce changement d'observer quelles fonctions d'une bibliothèque standard sont noexcept; Gabriel Dos Reis mentionne que notre traitement de la bibliothèque standard est un peu incohérent, mais rappelle que constexpr a déjà passé par un processus semblable, et estime qu'en donnant de la latitude aux développeurs des bibliothèques on se complique l'existence; Alisdair Meredith rappelle que l'on a l'opérateur noexcept qui permettait déjà d'observer si une fonction est noexcept ou non, Herb Sutter et Ville Voutilainen mentionnent tous deux que la plénière n'est pas le moment de tenir cette discussion; John Spicer dit que ce que cette proposition règle est quelques loopholes, quelques trous malheureux dans le langage), approuver __has_include, améliorer la terminologie NSDMI. On a aussi retravaillé les règles pour les constructeurs hérités (ce qui règle huit Core Issues d'un coup), le retrait de cas par défaut pour les Unary Folds. On a aussi réglé un petit bogue agaçant sur l'intialisation d'agrégats pour les classes de base, mais ce ne sera pas proposé cet après-midi. Nous avons aussi rencontré Gor Nishanov pour faire progresser la terminologie des coroutines; tenu une téléconférence avec Torvald Riegel sur les Forward Progress Guarantees. Le texte a été amélioré pour le remplacement d'objets contenant des références, ce qui est en fait une discussion sur ce qu'est un objet et sur les conversions valides. Une propsosition sur les enum class utilisées à titre de Strong Typedefs a été traitée, nous avons discuté d'une spécification fornelle pour l'ordre d'évaluation, et nous devrions discuter des modules demain matin. Nous prévoyons une télérencontre début décembre. Herb Sutter fait une motion de félicitations, tout le monde applaudit.

On aborde les motions de CWG :

LWG (Marshall Clow) : on avait quelques propositions à nous mais on en a reçu plusieurs de LEWG aussi. Dans nos gros dossiers, il y avait les intervalles, scope_exit, le type variant... Nous présentons toutefois plusieurs propositions devant vous :

Motion 1, plusieurs sont amenées en bloc. Unanime

Motion 2, quelques dossiers sont Tentatively Ready. Ville Voutilainen indique que le cas P2510 des étiquettes qui ne sont pas Default-Constructible est un Breaking Change. Jason Merrill indique que CWG a réglé le problème sur le plan normatif avec P1518. Clark Nelson suggère que l'on ne traite pas ce dossier aujourd'hui. Unanime

Motion 3, suppression des anciens alias pour les iostreams. Alisdair Meredith explique ce qui a bel et bien été supprimé. C'est du ménage. Unanime

Motion 4, P0006R0, le alias _v pour les valeurs dans les traits. Vote : consensus (des abstentions, mais pas de contre)

Motion 5, P0092, des ajouts à std::chrono. Chandler Carruth indique qu'il n'y avait pas de motivation dans le document; Howard Hinnant indique que les duration_cast et time_point_cast existants « tronquent » vers zéro plutôt qu'arrondir, ce qui permet des conversions de meilleure qualité. Chandler Carruth se dit préoccupé des conversions qui impliqueraient des dates et des fuseaux horaires. Howard Hinnant indique que les concepts de date et de fuseaux horaires n'existent pas dans le langage. Les deux échangent. Pablo Halpern demande s'il existe des facilités pour convertir de time_point à des heures, jour et mois Howard Hinnant liste ce que la bibliothèque standard existe présentement, et précise que nous n'avons rien pour les jour, mois et autres. John Lakos relate une présentation qu'il jugeait excellente de... Google à CppCon 2015 et estime que les préoccupations sont orthogonales. Chandler Carruth dit que les experts de Google sont opposés à cette proposition. Vote : consensus pour. C'est un peu tendu

Motion 6, P0007R1, constant_view. Unanime

Motion 7, P0156R0, lock_guard variadique. Ville Voutilainen demande si ça a été implémenté. Hans Boehm dit oui. Quelqu'un demande si ça fonctionne. On rit un peu

Motion 8, P0005R2, not_fn (retirer not1 et not2, les deux derniers lieurs du passé qu'il nous reste). Quelqu'un demande si on retire des trucs préalablement dépréciés. La réponse est non, ils n'étaient pas dépréciés. On se demande si on brise du code, la réponse est oui mais un vendeur peut l'offrir de manière non-portable (à titre d'extension) à sa convenance. Gabriel Dos Reis demande si les noms not1 et not2 sont conservés pour le futur. On demande s'ils sont dangereux; Stephan T. Lavavej dit que non, mais ils ne sont pas génériques et ne fonctionnent pas avec des λ. Le fait que l'on retire des objets sans dépréciation a priori est mal vu par certains membres de l'audience. Alisdair Meredith est d'avis que le code qui dépendait de not1 et not2 est probablement déjà parti avec la suppression des vieux lieurs. Vote : consensus pour, beaucoup d'abstentions. Deux pays sont contre alors ça bloque (les positions de pays sont plus fortes ici que les positions d'entreprise). Herb Sutter explique que la suppression sans dépréciation peut être bloquée par une position de pays. Alisdair Meredith va écrire le texte qui sépare le volet dépréciation et le volet ajout, mais ça va prendre du temps donc ça ira à Jacksonville

Motion 9, P0074R0, rendre owner_less plus flexible. Unanime

Motion 10, P0013R2, logical type traits. On a choisi conjunction, disjunction et negation comme noms finalement. Vote : consensus pour

Je suis allé voir Michael Wong à la pause pour lui demander ce que je dois faire pour avoir mon droit de vote à la plénière; je me retiens de voter depuis le début dû à mon titre officiel de « non-participating member », du fait que j'ai été partie prenante de plusieurs des débats qui ont mené à des votes jusqu'ici.

Il se trouve que j'aurais pu voter (grrrr...) puisque je suis envoyé par le Canada. La seule subtilité est qu'officiellement, si on demande la position du pays, c'est à Michael Wong de trancher, et pour cela il se base sur nos votes individuels. Je participerai donc à partir de maintenant, comme je l'avais fait à Lenexa (mais je pensais avoir fait une bêtise par la suite). Le statut de « non-participating member » est un bête truc d'inclusion dans un bottin, et ça doit être fait par Stephen Mitchell qui est notre « chef » pour les Conseil canadien des normes, volet langages de programmation, mais je demeure mandaté pour prendre position, même en plénière (dans les groupes de travail et d'étude, je savais déjà que c'était correct).

On poursuit les votes.

Motion 11, P0050 (observer_ptr et autres) unanime

Motion 12, Library Fundamentals TS2, unanime

Motion 13, N4531, offrir un remplacement pour std::rand() par quelque chose de moins dangereux. Stephan T. Lavavej dit que std::rand() est encore là mais qu'il ne faut pas y toucher

Motion 14, inclusions de conjunction, disjunction et negation dans le TS. Unanime

Motion 15, concurrency TS, P0159. Vote : consensus pour

Motion 16, mettre en place un comité éditiorial pour créer le document et le mettre en forme. Le Project Editor sera Arthur O'Dwyer. Unanime

Jeffrey Yasskin prend la scène

Motion 1, P0112R1, créer une TS officielle pour la Networking Library. Unanime

Motion 2, créer une TS officielle pour les intervalles basé sur P0021R0. Unanime. Applaudissements pour Eric Niebler

Motion 3, créer une TS2 officielle pour les extensions de parallélisme, N4505. Unanime. Ce sera la première TS avec modifications dûes à l'expérience

Motion 4, créer une PDTS officielle pour les Library Fundamentals, sur la base de N4529. Ceci inclura la TS originale. Unanime. Herb Sutter dit que ce passage direct d'une TS à une PDTS d'un coup sera peut-être une première dans l'histoire d'ISO. Bravo!

Clark Nelson dit qu'il nous reste à traiter SG10, Feature Test Macros. Il rappelle d'abord qu'il fait très chaud ici, et il ne souhaite pas que les discussions dérapent. Il espère une discussion, suivie d'un vote qui, idéalement, appuiera les travaux de SG10.

Clark Nelson rappelle ce que fait SG10 et ce que ce groupe d'étude ne fait pas. Le rôle du groupe est d'encadrer les macros pour fins de Feature Test pour le standard, et ceci se fait pour le moment sur une base annuelle, grosso modo. Il rappelle aussi que le support pour ce mécanisme est optionnel, reposant sur un TS. Nous cherchons à faire en sorte que ces macros (a) soient raisonnables / pertinentes, (b) soient répertoriées. Clark Nelson dit avoir recommandé à un auteur quelque chose qui n'avait pas de sens, ne se souvient pas de la raison de son erreur, et souhaite éviter que cela ne survienne à nouveau.

Clark Nelson dit souhaiter que plus de gens supervisent et surveillent le processus de sélection et d'attribution de macros pour fins de Feature Tests. Il indique que SG10 n'a pas le pouvoir d'imposer une pratique aux autres; son appel est une demande d'aide. Même le comité entier ne peut imposer une politique, ce n'est pas son rôle.

Clark Nelson dit souhaiter un vote pour savoir la position de WG21 sur les macros de Feature Tests.

Chandler Carruth ne voit pas beaucoup d'impact immédiat de cette démarche; selon lui, l'impact réel de cette pratique prendra sa valeur à long terme. Un autre indique que sa compagnie a beaucoup de code, un peu monolithique, et que ces mécanismes leur seront sûrement utiles.

Alan Talbot demande où se trouve le document des macros de Feature Tests. Clark Nelson le guide vers le lieu. Chandler Carruth lance qu'on devrait utiliser un moteur de recherche comme Bing (!) pour chercher ce document; semble que ce soit très efficace. On rit un peu.

On discute un peu pour délimiter la question qui sera soumise au vote. Ça converge vers un votre d'encouragement.

Gabriel Dos Reis demande si on devra se conformer à ces macros. Clark Nelson didit que ça n'ira pas dans le standard.

Le vote est pris. Consensus pour

Tony van Eerd demande si on doit examiner des mécanismes pour que les gens fassent le travail maintenant. Clark Nelson est d'avis que ce n'est pas pertinent du fait que le vote parlait d'encourager, sans plus

Les gens commencent à s'agiter car ils veulent aller travailler. On fait un tour rapide de l'ordre du jour de demain, et on nous signale que la séance de travail sur std::date ce soir a été annulée.

La prochaine rencontre débutera le ... 29 février 2016 à Jacksonville, puis la suivante sera le 20 juin 2016 à Oulu en Finlande. Il n'y aura pas de séances de soirée... car il n'y aura pas de soirée en Finlande à cette date  Les subséquentes devraient être à San Diego, puis quelque part en Oklahoma (dans l'ordre ou dans le désordre), et la suivante devrait être en Angleterre pour l'été 2017.

Les échéances pour les prochaines livraisons de propositions sont le 6 novembre 2015 pour le post-Kona, et le 12 février pour le pré-Jacksonville.

On arrête à 17h15 environ. Pour demain, reste les travaux du matin, les votes de l'après-midi, puis une douche et on s'envole. Je suis fatigué.


Mes voyages de 2015 sont ... particuliers, disons, sur le plan du réseautage. Celles et ceux qui ont lu mon rapport de voyage à CppCon 2015 savent à quel point j'y ai été impliqué (ça devrait aller en croissant, à l'oeil), et vous êtes à même de voir que je n'ai pas chômé à Kona non plus si vous lisez ceci.

Ce soir, j'étais fatigué. J'avais promis à Jocelyn, adorable papa de mon amoureuse Za, que j'essaierais d'aller prendre un Mai Tai (la photo sur le lien est assez juste, mais j'avais un parasol plutôt qu'une fleur) pendant mon séjour ici, même si les consommations sucrées c'est plus ou moins mon genre. Il y a un petit restaurant pas loin de l'hôtel où ça sent bon et où je ne suis pas allé, du fait que c'est un peu cher pour mes moyens (pas dramatique, mais pas quelque chose que je me paierais au quotidien), et qui annonce servir cette mixture. J'y suis all. faire un tour vers 18h mais, même seul, il n'y avait pas de place pour moi sans réservations. J'ai donc pris une réservation pour un peu plus tard, vers 19h30, et je suis revenu à ma chambre.

J'en ai profité pour bavarder un peu avec mon amoureuse. Elle me manque.

Mon plan était d'aller m'asseoir sur le bord de l'eau avec le drink en question, quelques crayons et un peu de papier, puis dessiner en respirant. Quand je suis retourné vers le petit resto, il se trouve qu'un petit groupe composé de J. Daniel Garcia, Michael Wong, Aurélien Regat-Barrel, Bjarne Stroustrup, Lawrence Crowl et Jean-Christian van Winkel attendait une place. Ils m'ont accueilli chaleureusement et m'ont offert de me joindre à eux; je ne voulais pas m'imposer mais en même temps, l'ambiance était agréable et j'ai pris l'offre.

J'ai passé deux heures fort plaisantes à bavarder de la vie, de C++ évidemment, de culture, etc. avec ces très chic et très pertinentes personnes. Le repas était bon (j'ai pris des raviolis de homard et de crabe; les autres ont pris des assiettes de fruits de mer qui semblaient délicieuses pour pa plupart mais ça aurait été trop pour moi dans cette température), j'ai pris le Mai Tai promis et de la bière locale très correcte, nous étions au bord de la mer, et je dois avouer que j'ai apprécié le privilège du moment. Je travaille fort, mais je suis à ma place et c'est correct qu'il y ait des récompenses comme ça de temps en temps.

Je vous écris donc ceci avant d'aller me coucher. Il est 22h20 environ ici, et c'est le départ demain (journée très longue qui s'annonce) alors je vais me reposer.

Jour 6 24 octobre 2015

Dernier matin à Kona. Je me lave, paquete mes trucs, et je vais au petit resto d'à côté pour prendre quelque chose à manger. Folie, je me commande un oeuf (je n'en ai pas mangé de la semaine) alors il y a un petit délai. J'attends mon déjeuner en sirotant un café et Bjarne Stroustrup passe dire bonjour. On bavarde un peu, rien de profond, juste la vie, la gestion du stress, les impressions de la semaine. On se salue, il part de son côté, mon oeuf arrive, je fais de même. Herb Sutter est en ligne comme je sors, on se salue en souriant. Je pense qu'on est tous relativement satisfaits de la semaine.

Le déjeuner était correct (un peu cher, mais pas vilain). Par contre, il y avait une généreuse tranche de papaye à côté de mon petit wrap. Je sais que c'est un phénomène connu, mais répétons-le : la papaye fraîche que l'on peut manger dans un endroit comme celui-ci n'a rien à voir avec la chose insipide qui se rend dans nos supermarchés nordiques. C'est probablement le fruit qui perd le plus de sa saveur dans de telles circonstances.


Ma grosse question ce matin est de savoir si je retourne avec mes ami(e)s de CWG pour le matin ou si je vais travailler avec Marshall Clow et LWG. Les deux m'intéressent (Marshall Clow et son équipe sont aussi des gens très agréables à côtoyer); par contre, LWG travaillera dehors et il fait chaud, alors je pense que CWG va gagner.

Passé au Check-Out. Restait environ 1000 USD à payer (bobo!). Évidemment, on a inscrit mon nom comme Ms. Patrice Roy. Soupir...

Arrivé à la salle de travail de CWG, Jonathan Caves et un autre étaient déjà au boulot. L'hôtel avait fermé la climatisation, alors c'était plutôt lourd. Je ne sais pas s'ils sont habitués au rythme de travail d'un groupe comme celui-ci, ou au fait que l'on travaille six jours, pas cinq, lorsqu'on se rencontre. Aurélien Regat-Barrel m'en a d'ailleurs parlé hier midi, et est revenu là-dessus hier soir : il n'était jamais venu à une rencontre de WG21 en tant que tel, mais avait assisté à des rencontres d'autres groups par le passé, incluant des sous-groupes de travail ciblés de WG21 qui se rencontraient pour résoudre des problèmes pressants, et il était stupéfait de voir combien les journées de travail étaient longues et intenses. Je pense qu'il était content; je doute que les gens s'imaginent ce qu'il faut comme investissement personnel en temps et en énergie pour faire avancer des dossiers comme ceux que nous traitons ici, mais je suis certain que si les gens savaient, ils seraient un peu rassurés.

Nous sommes un bon groupe en ce samedi matin (en fait, nous sommes tous là, et il y a de nouveaux participants). Jonathan Caves, un autre collègue ici et moi-même partagerons peut-être un taxi pour l'aéroport.

Mike Miller explique le plan de match, qui est d'abord de prioriser les nouveaux Core Issues (il y en a 37). Il se peut que le travail se poursuive après la plénière alors je vais peut-être travailler avec eux.

2149. Brace elision and array length deduction

Il y a une ambiguïté sur la taille des listes d'initialisation en termes de nombres d'éléments. Il manque un concept (Brace Elision) dans le standard. P0.

2150. Initializer list array lifetime

Richard Smith pense que c'est un exemple incorrect, alors on détermine que c'est P0 éditiorial.

2151. Exception object is not created

Remis à plus tard, car le dossier est probablement réglé par la proposition de Richard Smith cette semaine.

2152. Can an alternative token be used as a ud-suffix?

Pervers., La grammaire telle qu'elle est exprimée semble permettre un truc comme "x"or"y" comme suffixe de littéral maison, ce qui donnerait true... Disons que c'est pas gentil. Il y en a qui utilisent des macros aussi. Jason Merrill dit qu'il a été étonné, en pratique, de voir combien de gens font des manoeuvres comme celle-là. Hubert Tong dit avoir mentionné ceci auparavant et s'être fait dire que les usagers sont supposés débuter leurs suffixes par un soulignement. On pense qu'on devrait le permettre, mais avec un soulignement, donc NAD.

2153. pure-specifier in friend declaration

Oh, que c'est méchant... On pourrait déclarer une méthode abstraite dans une autre classe avec ça. P0

2154. Ambiguity of pure-specifier

C'est une forme grammaticale ambiguë. Mike Miller va s'en occuper. P0

2155. Defining classes and enumerations via using-declarations

Il manque une règle de production grammaticale pour vraiment résoudre un problème que l'on croyait résolu.

2156. Definition of enumeration declared by using-declaration

Connexe

2157. Further disambiguation of enumeration elaborated-type-specifier

Truc grammatical

2158. Polymorphic behavior during destruction

C'est laid et malpropre et faut corriger la terminologie pour l'expliciter. La formulation va ressembler à celle des constructeurs mais sera un peu différente (il y a un const qui influence un peu l'expression dans le problème présenté)

2159. Lambda capture and local thread_local variables

L'exemple est intéressant :

void f() {
   thread_local int n = 10;
   std::thread([&] { std::cout << n << std::endl; }).join();
}

Ici, l'affichage sera zéro, pas 10, car le n capturé par référence n'est pas dans le thread anonyme qui est lancé. Remplacer [&] par [n = n] réglerait le problème. On pense que ce n'est pas un bogue (on pourrait avertir, au mieux), mais on va demander l'avis de SG1.

2160. Issues with partial ordering

L'explication est sur https://github.com/cplusplus/draft/issues/523 et c'est amusant. P1 pour le moment. Richard Smith pense que ça vaut la peine d'être spécifié. Il se peut qu'on la réduise à P2.

2161. Explicit instantiation declaration and "preceding initialization"

Amusant. Selon Richard Smith, c'est réglé vec C++ 14 mais faudrait indiquer que c'était un bogue de C++ 11. NAD

2162. Capturing this by reference

Une clarification requise pour qu'il soit clair que this est capturé par valeur. Jason Merrill demande s'il existe une proposition pour ceci. Semble que le texte actuel prétende que this est capturé par référence. C'est faux. P0

2163. Labels in constexpr functions

C'est pas permis mais on pense qu'on devrait. Faut juste pas écrire le texte de manière telle que cela empêcherait d'écrire un switch dans un constexpr.

2164. Name hiding and using-directives

Une question de lookup avec un identifiant et des namespaces. Le texte dit des trucs semblables à deux endroits, mais différemment, et c'est un irritant. Techniquement, un même nom est visible de deux sources distinctes.

2165. Namespaces, declarative regions, and translation units

On utilise le terme declarative region en parlant d'un namespace mais ça ne rejoint pas bien la définition de declarative region qui est « Every name is introduced in some portion of program text called a declarative region, which is the largest part of the program in which that name is valid, that is, in which that name may be used as an unqualified name to refer to the same entity ». Mike Miller va la prendre. P1

2166. Unclear meaning of "undefined constexpr function"

Le point de définition d'une fonction constexpr est sous-spécifié. Ça ne pose pas de problème en pratique mais c'est agaçant, et les implémentations divergent. Hubert Tong s'en occupe.

2167. Non-member references with lifetimes within the current evaluation

On a un cas omis dans la définition de ce qu'est une id-expression. Ça se corrige simplement. P0. Jens Maurer s'en occupe.

2168. Narrowing conversions and +/- infinity

La capacité de traiter certaines conversions sur des nombres à virgule flottante, en particulier pour ce qui a trait à l'infini lors de la compilation, est sous-spécifiée. Hubert Tong dit qu'il ne serait pas heureux qu'une conversion soit non-narrowing dû à un débordement vers l'infini. Richard Smith dit que sur la majorité des machines, on n'aura pas de problème, mais estime que le problème est subsumé par le problème plus général de la cohérence des nombres à virgule flottante. On l'envoie à SG6

2169. Narrowing conversions and overload resolution

Exemple amusant :

struct s { long m };
struct ss { short m; };
void f( ss );
void f( s );
void g() {
   f({ 1000000 }); // Ambiguous in spite of narrowing for f(ss)
}

On hésite initialement entre NAD et ill-formed, car le narrowing n'intervient pas à ce stade dans le processus. On compte préciser le texte. Richard Smith mentionne qu'on est incohérents avec ce qui se passe avec les templates ici, où le narrowing intervient pour la résolution. On décide de s'en occuper. On blague pas mal sur l'intialisation uniforme, qui complique franchement la vie des gens en pratique (il y a tellement de Corner Cases)... On va y revenir, car ce qu'il faut faire n'est pas clair. P1

2170. Unclear definition of odr-use for arrays

Le texte expliquant ODR-usage pour la définition des tableaux (entre autres) est confuse.

2171. Triviality of copy constructor with less-qualified parameter

Un constructeur de copie comme T(T&) = default; sans const serait non-trivial, mais c'est probablement trop strict.

2172. Multiple exceptions with one exception object

Avec un std::exception_ptr, il devient possible pour un même objet de gérer plusieurs exceptions à l'interne. Le texte n'est probablement pas clair sur l'intention en ce sens, en particulier sur la libération des objets. C'est un jeu terminologique. P0

2173. Partial specialization with non-deduced contexts

Truc amusant. Ceci :

template <int I, int J> struct B {};
template <int I> struct B<I, I*2> {};

... est mal formé. On dit P1 et ça recoupe 2160. Jason Merrill n'est pas sûr que ce soit sain de toucher à ces règles.

2174. Unclear rules for friend definitions in templates

Le texte est confus, mais c'est long. Le problème est de savoir quand la fonction friend commencera son existence. On s'entend pour dire que la proposition se tient, mais c'est des templates alors on va y réfléchir et on réserve notre jugement pour l'instant.

2175. Ambiguity with attribute in conversion operator declaration

La méthode suivante, si perverse soit-elle, pose problème :

operator int [[noreturn]] ();

Oublions l'étrangeté d'un opérateur de conversion en int qui soit [[noreturn]], la question est de savoir à quoi [[noreturn]] s'applique. Faudra clarifier la règle, évidemment. Aaron Ballman propose P3. Richard Smith trouve un passage qui suggère NAD. On convient de P3 et Jens Maurer va écrire quelque chose.

2176. Destroying the returned object when a destructor throws

Richard Smith propose l'exemple suivant :

#include <cstdio>
struct X {
   X() { puts("X()"); }
   X(const X&) { puts("X(const X&)"); }
   ~X() { puts("~X()"); }
};
struct Y { ~Y() noexcept(false) { throw 0; } };

X f() {
   try {
      Y y;
      return {};
   } catch (...) {
   }
   return {};
}
int main() {
   f();
}

On a X() deux fois ... et ~X() une fois. C'est une défectuosité de C++ 98.

2177. Placement operator delete and parameter copies

RS dit que celle-ci laisse des cicatrices :

void *operator new(size_t n, std::string s) {
   std::string t = std::move(s);
   std::cout << "new " << t << std::endl;
   return operator new(n);
}
void operator delete(void*, std::string s) {
   std::cout << "delete " << s << std::endl;
}
struct X { X() { throw 0; } };
int main() {
   try {
     new ("longer than the small string buffer") X();
   } catch (...) {}
}

Nos implémentations courantes affichent "new longer than the small string buffer" puis "delete". Ouch.

2178. Substitution of dependent template arguments in default template arguments

Ceci confond nos compilateurs :

template<typename T, T V, int n = sizeof(V)> using X = int[n];
template<typename T> void f(X<T, 0>*) {}
void g() { f<char>(0); }

Jens Maurer propose P1.

2179. Required diagnostic for partial specialization after first use

John Spicer rapporte un problème dans la spécification de la manière dont les spécialisations partielles des templates sont instanciés dans plusieurs unités de traduction. Par exemple :

template <class T1, class T2> class A;
template <class T> struct A<T, void> { void f(); };
template <class T> void g(T) { A<char, void>().f(); }   // #1
template<typename T> struct A<char, T> {};
A<char, void> f;   // #2

Ici, on ne sait pas si #1 ou #2 est le premier cas d'utilisation de A<char,void>. P1 et on va y réfléchir.

2180. Assignment operators and potentially-constructed subobjects

On a des problèmes d'accès à la soumission alors Mike Miller nous la lit. Jens Maurer va l'arranger.

On prend une pause, puis Gabriel Dos Reis devrait venir regarder la formulation modules avec nous. Mike Miller dit qu'on aura une téléconférence en décembre pour réexaminer cette question par la suite.

Dinka Ranns demande pourquoi une classe qui a des opérations de copie =delete mais un des opérations de mouvement =default demeure TriviallyCopyable. Hubert Tong indique que l'idée derrière TriviallyCopyable est que l'objet peut être dupliqué par voie de memcpy(), ce qui serait le cas ici.

Petite pause. Je bavarde avec quelques collègues. Jonathan Caves et moi convenons que nous préférons arriver plus tôt à l'aéroport que plus tard, pour réduire les risques de problèmes bêtes. Aurélien Regat-Barrel me prend en photo pour appuyer une éventuelle entrevue écrite (je suis toujours aussi peu photogénique). On se réinstalle en place pour les travaux sur les modules avec Gabriel Dos Reis.

Gabriel Dos Reis met a plus récente version de son document à notre disposition. Gor Nishanov se joint à nous de même que quelques autres. Le document est D0143R0 et est une retouche de N4466

Gabriel Dos Reis explique :

Gor Nishanov demande si un export peut apparaître avant un module. Il ne trouve pas la règle pour expliciter ce que l'on fait.

Les fonctions inline et constexpr peuvent être exportées d'un module si elles y sont définies.

Jason Merrill dit qu'il aimerait que le texte parle de module linkage, un concept qui n'est pas clairement présent dans le texte. Gabriel Dos Reis n'est pas sûr. Selon Jason Merrill, ce serait vraiment la chose à faire.

Dans §3.1 p2, Roger Orr aimerait un exemple pour clarifier le propos dans le standard.

Gabriel Dos Reis parle de proclaimed-module-ownership dans le cas où il y a des dépendances implicites entre deux modules (l'un présume des exportations de la part de l'autre et inversement).

Dans §3.2 p6, Jens Maurer souligne que le passage qui discute d'ODR (où on aurait une violation d'ODR normalement) pose problème dans le cas du module global, donc il faudrait clarifier cette exclusion.

Jason Merrill demande si une classe X définie dans deux modules distinctes provoque une violation d'ODR. Gabriel Dos Reis dit seulement si elles sont exportées. Hubert Tong fait remarquer que ce n'est pas ce qu'indique le texte courant. Jason Merrill explique que c'est l'une des raisons pour lesquelles il souhaite un module linkage. Hubert Tong voit une autre violation d'ODR possible pour les extern "xyz"{ ... } mais Gabriel Dos Reis estime que dans le contexte d'un module l'exemple en question serait ill-formed. Jason Merrill se dit surpris que l'on change le sens du langage existant. On a un peu de ping pong sur la question de savoir s'il est sage ou non de briser ce cas.

John Spicer parle de §7.7 p2, le import, pour clarifier le sens à lui donner. Gabriel Dos Reis dit que c'est plus comme un using que comme un #include; on n'a pas à retraiter les noms à ce stade et ça ne devrait pas changer le Name Lookup. John Spicer demande quel sera l'impact si des fonctions f() sont déclarées dans le module importeur et dans le module importé sont une même fonction ou non; Gabriel Dos Reis dit que c'est une question de namespace. John Spicer dit que c'est plus comme une using declaration que comme une using directive.

Maxim Kartashev demande quand on considère si une entité est définie ou non. Gabriel Dos Reis dit que c'est au point d'utilisation (si on n'utilise pas un nom, il n'y a pas de conflit). Dans ce cas, c'est plus comme un using directive que comme un using declaration. On demande une clarification terminologique pour mieux définir la visibilité, et de placer cette clarification dans la section qui s'y prête. Jens Maurer demande une précision sur le sens d'un import-declaration.

Dinka Ranns demande si le module globale « possède » quelque chose. Le texte parle beaucoup de ce que possèdent les modules, mais ce cas reste sous-spécifié. Gabriel Dos Reis dit que ce qui n'est pas « possédé » par un module est « possédé » par le module global. Jason Merrill suggère de remplacer owned par in-the-purview-of en général.

Roger Orr remarque quelques étrangetés grammaticales. Gabriel Dos Reis explique sur quoi il s'est basé. On clarifie un peu le portrait.

John Spicer remarque une définition circulaire dans §14.7 p8. Gabriel Dos Reis va corriger.

Hubert Tong a une question générale : doit-on traduire les implémentations d'un module importé pour générer des diagnostics s'ils ne sont pas utilisés? Jason Merrill pense que oui.

John Spicer demande si on module qui exporte des trucs doit être compilé avant un truc qui les importe. Gabriel Dos Reis dit que c'est implementation-defined mais que ça devrait être spécifié.

Jason Merrill demande si §16.2 du standard doit être adaptée pour clarifier la « découverte » des modules, là où on explique #include. Gabriel Dos Reis est d'accord.

John Spicer demande comment le name lookup des noms dépendants fonctionnera avec les spécialisations de templates. Gabriel Dos Reis explique. John Spicer suggère qu'on clarifie la mécanique. Gabriel Dos Reis était d'avis qu'il n'y avait pas de changements, mais John Spicer fait la démonstration que ce n'est pas le cas. On va ajuster le texte.

Jens Maurer demande si export{a;b;c;} sera équivalent à export a; export b; export c;. Gabriel Dos Reis dit que oui. Jens Maurer fait remarquer une étrangeté grammaticale qui rend Gabriel Dos Reis perplexe; Gabriel Dos Reis va y réfléchir. Une exportation ne pourra se faire qu'au niveau global.

Je me questionne sur la possibilité pour une classe dans un module qui aurait pour amie une fonction dans un autre module. Gabriel Dos Reis dit que c'est légal.

Dawn Perchik se questionne sur la structure interne d'un module. Gabriel Dos Reis précise sa pensée. Gor Nishanov fait un dessin. Roger Orr demande quoi penser d'un module qui n'a pas d'exportations. Gabriel Dos Reis dit qu'il est plus ou moins intéressant.

Le dessin de Gor Nishanov ressemble à ceci :

+------------+-----------+-----------+-----------+
| module A;  | module A; | module A; | module A; |
| export ... |           |           |           |
+------------+-----------+-----------+-----------+
 ^^^^^^^^^^^^
  interface
  du module
 (une seule)

Richard Smith se questionne sur la relation de possession. Gabriel Dos Reis explique. Hubert Tong amène une sous-question. Gabriel Dos Reis dit qu'un module qui définit un nom le possède. Hubert Tong parle des variables globales. Il semble manquer un petit quelque chose, mais Jason Merrill suggère de ne pas s'en occuper s'il n'y a pas d'utilisation. Hubert Tong dit qu'il faudrait clarifier les lookup rules.

Richard Smith parle de deux unités de traduction. Une exporte une définition, une autre exporte une déclaration. S'agit-il d'un cas ill-formed? Parle-t-on d'un no diagnostics required? Gabriel Dos Reis suggère no diagnostics required. Richard Smith demande si une implémentation pourrait décider qu'il s'agit d'une seule et même entité. Gabriel Dos Reis dit oui. Hubert Tong est confus. Gabriel Dos Reis dit que la différence est que dans le cas évoqué par Richard Smith, les deux morceaux sont dans des unités de traduction distinctes. L'idée est en partie de permettre de mettre en Cache une instanciation. John Spicer a l'impression que le concept de ownership est sous-spécifié. Gabriel Dos Reis parle de pouvoir lier deux modules qui définissent des fonctions de même signature sans problème si ces signatures ne sont pas exportées.

Jason Merrill se questionne sur l'instanciation des templates et le linkage sur la base de leurs paramètres; il a l'impression qu'il faudrait que ça aille ensemble.

John Spicer parle d'une variable statique d'un template : dans quelle unité de traduction sera-t-elle définie? Faudra probablement qu'elle soit exportée. Gabriel Dos Reis dit qu'on pourrait l'accéder par une fonction.

Hubert Tong parle d'ADL et de la possibilité de découvrir une fonction qui sera définie ultérieurement. Gabriel Dos Reis dit que ça intervient dans la deuxième phase de lookup. Richard Smith dit qu'il arrive qu'une instanciation d'un template dépende d'une châine d'entités qui doivent être connues pour bien construire le template (ce fut une découverte pour eux), et explique les règles qu'ils ont mis en place pour adresser cette question. C'est important car cela donne un cas où des entités non-exportées peuvent intervenir dans un contexte où elles ne sont pas accessibles. Gabriel Dos Reis dit qu'il faut distinguer unité de traduction et unité d'instanciation. Richard Smith demande quel sens donné à internal linkage pour un module. Gabriel Dos Reis précise la distinction susmentionnée. Jason Merrill a l'impression que cela fonctionnera essentiellement comme les globales statiques aujourd'hui, mais d'une manière exposée à l'éditeur de liens.

Richard Smith suppose un module X qui a void f() non-exporté. Un autre fichier dans le même module peut-il utiliser f()? Gabriel Dos Reis dit oui. Et si f() a un internal linkage? Gabriel Dos Reis dit non. Il y a bel et bien trois niveaux de linkage dans le modèle. John Spicer voit un cas agaçant où on ne peut pas nécessairement savoir si on aura un jour besoin de quelque chose avant que quelqu'un s'en serve bel et bien, en particulier dans le cas des noms dépendants. Jens Maurer se dit triste qu'on doive encore exposer autant d'information aux frontières des modules, le but à ses yeux étant de réduire le travail à faire lors de l'édition des liens. On discute, c'est un sujet amusant qui a des ramifications d'ordre historique.

Richard Smith parle du risque d'inlining d'une fonction qui référerait quelque chose qui pourrait se trouver ailleurs. Gabriel Dos Reis dit qu'on ne peut le faire si la fonction en question est inambiguë. Gabriel Dos Reis indique que l'inlining est une optimisation qui n'est pas observable du point de vue de la machine abstraite; inliner ou non est une question d'implémentation.

Faut arrêter. Mike Miller dit qu'on va poursuivre les échanges lors d'une téléconférence en décembre. Gabriel Dos Reis mettra une version à jour de son document sur la liste de diffusion d'ici là.

On prend un pause pour respirer un peu et manger une bouchée. On se revoit en plénière cet après-midi, puis ensuite pour travailler encore un peu.

Je suis allé luncher avec Aaron Ballman, Roger Orr et son épouse (très gentille mais je ne connais pas son nom), Richard Smith, Hubert Tong et un collègue dont le nom m'échappe. Peu de temps après, Stephan T. Lavavej et Eric Niebler se sont joint à nous (j'ai surtout bavardé avec eux, question de position à table, mais c'était fort sympathique). Pas de la grande cuisine (un Sports Bar pas loin; la bière était correcte et j'ai pris un wrap au Mahi Mahi, mais ils avaient pané le poisson), mais un dîner fort agréable. Obtenir les factures a été plus long que prévu, alors nous sommes revenus pour 13h15... et tous les votes avaient été pris, aucun des aspect de la rencontre d'hier ne prêtant à controverse. Nous voilà donc de retour à CWG.

Mike Miller demande si on a de nouveaux trucs. Jason Merrill a quelque chose.

1496. Triviality with deleted and missing default constructors

Jason Merrill propose une formulation plus raisonnable pour TriviallyCopyable. Je fais une blague sur les double-négatifs, Jason Merrill retravaille à quelques reprises. On en fait un Tentatively Ready.

Core Issue 242: Interpretation of old-style casts (suivi)

On revient sur celle-ci. Du bon boulot, bravo! On en fait un Tentatively Ready.

Hubert Tong veut discuter de dossiers sur le Reflector's mais je ne les ai pas encore. Le 28323 semble être un cas pathologique qui n'affecte à peu près personne. Je n'ai pas suivi pour l'autre.

Mike Miller dit qu'il y a eu du trafic à propos de __has_include. Le message est 28324. La grande question et de savoir comment la macro s'étendra en pratique. L'exemple proposé par Hubert Tong est une horreur de méchanceté 

1255. Definition problems with constexpr functions

J'exprime un gros malaise envers les exemples des paragraphes 8, 9 et 10, qui sont présentés comme incorrects mais qui, à mes yeux, devraient l'être. Je suis d'avis que nous allons trop loin. Ça semble rejoindre les gens dans la salle. Il y a des difficultés sérieuses à une approche plus générale, mais les exemples triviaux qui sont présentés semblent difficiles à justifier. Le problème est le cas général, qui demande une machine à voyager dans le temps. Ouf...

En gros, un truc comme ceci est illégal :

struct X {
    static constexpr int f() { return 3; }
    int tab[f()];
};

... car le sens de X::f() n'est pas – en général – connu avant la fin de la déclaration de X. On a plusieurs cas semblables. Le problème est que le cas simple semble évident, mais le cas général est un cauchemar total et absolu (idem pour le recours à sizeof(f()) et autres).

1271. Imprecise wording regarding dependent types

Ce texte propose une simplification terminologique pour les cas où typename est requis. Ça me semble pas si mal, mais c'est pas assez pour convaincre les gens qui écrivent des compilateurs dans la salle

1284. Should the lifetime of an array be independent of that of its elements?

On parle ici d'une précision terminologique à propos de la durée de vie des tableaux. On fait un petit ajustement pour alléger l'écriture. Ça s'en va à Tentatively Ready. Il y a des subtilités entre tableau et éléments du tableau...

1341. Bit-field initializers

Richard Smith fait remarquer que le changement proposé entraînerait une ambiguïté grammaticale, soit l'ajout d'initialisation avec accolades pour un chanmp de bits. Mike Miller propose NAD.

Richard Smith propose un exemple horrible :

struct X {
    int x : 1 || new int { 3 }; // piarkkk
 };

... qui serait sémantiquement absurde mais sémantiquement incorrect. On pourrait empirer la situation en ajoutant une virgule :

struct X {
    int x : 1 || new int, { 3 }; // piarkkk++
 };

Jens Maurer se demande si l'opérateur d'affectation pourrait faire le travail. Richard Smith dit non parce que :

struct Y {
    int y : true ? 1 || n = 0; // oh boy...
 };

On convient de NAD.

1638. Declaring an explicit specialization of a scoped enumeration

C'est obscur, mais c'est clair  . Tentatively Ready.

1699. Does befriending a class befriend its friends?

Non pour le titre. Le texte proposé est pas mal. Richard Smith pose la question de classes internes à l'ami; j'admets que c'est obscur. Mike Miller suggère qu'on demande à l'auteur de la proposition d'exprimer l'intention plus en détail.

On arrête vers 15h5 car des gens commencent à se préparer pour prendre leur avion. On bavarde un peu pour le plaisir. Daveed Vandevoorde a de la famille à Montréal, apparemment.

Je n'utiliserai finalement pas la chambre de courtoisie pour prendre ma douche; on a peu de temps et j'ai travaillé à l'air climatisé cet après-midi. Jonathan Caves mm'a confié préférer partir plus tôt, vers 16h30, et je pense que je vais quitter avec lui. J'ai hâte d'être à la maison et tout ce qui peut réduire les risques de problèmes en route me convient.

Il fait plein soleil ici; je me trouve une chaise à l'ombre pas loin d'une prise de courant et d'un ventilateur, puis je bavarde un peu avec mes grandes Marguerite et Calypso par Skype tout en suivant l'évolution du pointage du match du Canadien de Montréal (on se dirige vers une neuvième victoire consécutive en début de saison, c'est quand même pas rien!)

Après une trentaine de minutes, Jens Maurer est venu m'avertir que la grande salle où j'étais installé accueillera un mariage sous peu, alors je suis retourné profiter de la salle de travail climatisée en attendant le moment du départ. J'ai profité d'un peu moins d'une heure pour travailler et écouter la fin du match de hockey (victoire!), puis Jens Maurer (qui était parti prendre des photos de palmiers pour son épouse) est venu m'avertir que le taxi que je partageais avec Jonathan Caves était déjà arrivé. Je me suis dépêché, nous avons roulé jusqu'à l'aéroport... et j'ai oublié ma (très bonne!) tasse thermos pour le café derrière moi. Bon.

Nous sommes arrivés un peu en avance à l'aéroport. J'ai pris quelques photos (sans doute médiocres, mais bon, j'essaie... C'est juste pas moi) de l'endroit pour ma petite famille, et Jonathan Caves et moi sommes allés prendre une bière et bavarder pour passer le temps. C'est un individu à la fois sympathique et pertinent. Alisdair Meredith est arrivé un peu plus tard et s'est joint à nous; il travaille chez Bloomberg mais son emploi précédent était pour Renault en formule 1. On a bavardé un peu ensemble, mais ça changeait beaucoup la dynamique.

Sans surprises, la bouffe coûte une fortune ici, alors je ne mangerai pas, et si mon souvenir est bon, je ne mangerai pas à Los Angeles non plus. Dormons, nous mangerons demain.

Le WiFi à l'aéroport est presque inexistant, alors on oublie ça (en fait, il y a une page d'accueil, une option pour améliorer le service moyennant des frais, mais aucun moyen d'avoir accès au service de base...). J'ai bavardé un peu avec Botond Ballo, qui comme Alisdair Meredith s'en allaiut vers Denver. Jonathan Caves était en attente près de la seule prise de courant qui semblait fonctionner, alors je me suis permis de la partager avec lui, puis Jason Merrill s'est joint à nous... avec une barre multiprise  C'est de mon siège, en attente du vol, que je vous écris ceci.

Quand est venu le temps de passer à la deuxième douane (car il y en a deux ici : j'ai été fouillé à l'entrée, et testé pour possession d'explosifs, et on a re-fouillé mes sacs quand je suis passé la frontière où il n'y avait plus de commerces pour qu'on s'assure que je n'avais pas de nourriture fraîche avec moi), j'ai fermé mon ordinateur, patienté, puis je suis passé. J'ai croisé Billy Baker qui, sachez-le, est franchement sympathique (il me fait beaucoup penser à mon grand chum Patrick Hubert, que je ne vois pas assez souvent – comme tous mes amis, je sais – mais je ne pourrais pas dire pourquoi). De l'autre côté, je me trouve une prise de courant, je me branche, j'ouvre l'ordinateur et... Blue Screen. Troisième crash de la semaine, deux « bleus » et un « noir ». Ma vieille machine souffre.


LAX, l'aéroport de Los Angeles, est un étrange endroit. Là où je suis cette fois, c'est archi moderne, j'ai un excellent service, et le lever du soleil est magnifique. Par contre, pour l'organisation, c'est ... difficile à qualifier. Mon collègue Tony van Eerd, qui va vers Toronto et arrivait sur le même vol que moi, a sûrement manqué son transit (mon vol est à 8h, le sien était à 7h). Il faut comprendre que LAX est fait de plusieurs terminaux, que le passage de l'un à l'autre se fait par navette (faut sortir du terminal, aller là où les voitures passent, prendre une navette et entrer ailleurs), que les indications pour trouver une navette sont ... présumées connues de tous (il n'y a aucun panneau, nulle part), qu'il faut savoir qu'il faut la navette A pour aller au terminal 2 (c'est aussi du savoir a priori, il n'y a pas d'indications), et qu'on peut voir passer plusieurs navettes C avant de voir passer une navette A... Quand la conductrice de la navette A est enfin arrivée, elle nous a dit que ce qui avait été long avait été de trouver une navette climatisée... Je suis certain que celles et ceux qui auront manqué leur vol ont apprécié.

À l'intérieur du terminal d'où je partirai, c'est plus agréable et bien mieux organisé que dans le terminal par lequel je suis parti vers Hawaii. On nous accueille en français et c'est apprécié. Par contre, le WiFi gratuit est aussi merdique que la dernière fois, et j'abandonne (à contrecoeur) l'idée d'écrire un mot d'amour à ma belle.

À suivre pour les conclusions...

Aide-mémoire

Trucs que je retiens de la journée :

Trucs à retenir, d'ordre plus général :

À faire la prochaine fois, avant de me présenter à la rencontre :

Glossaire

Plusieurs tPlusieurs termes tirés du jargon du comité apparaissent dans ce document. J'ai essayé de les regrouper ici. Tout ce qui suit est informel, alors prenez-le avec un grain de sel.

Acronyme Signification En détail (informellement)

ABI

Application Binary Interface

La forme que prend l'interface compilée entre les modules (au sens large du terme) d'un système. En C++, il n'y a pas d'ABI commune entre le fruit des implémentations de divers vendeurs, alors cette question est sensible

CWG

Core Working Group

Le groupe de gens qui cherchent faire raffiner ce qui est au coeur du langage, incluant la grammaire, les éléments qui impliquent l'ajout de mots clés (mots de vocabulaire ayant un rôle prédéfini) contextuels ou non, ce genre de truc. Intersecte en partie avec EWG

DTS

Draft Technical Specification

Document de type « premier jet », qui se veut complet et est soumis à la discussion mais n'a pas encore à être implémenté (sauf à titre volontaire et expérimental)

EWG

Evolution Working Group

Le groupe de gens qui cherchent faire avancer le langage à proprement dit, incluant la grammaire, les éléments qui impliquent l'ajout de mots clés (mots de vocabulaire ayant un rôle prédéfini) contextuels ou non, ce genre de truc. Intersecte en partie avec CWG

IS

International Standard

La norme à laquelle les implémenteurs doivent se conformer.

LEWG

Library Evolution Working Group

Le groupe de gens qui cherchent à voir dans quelle direction faire évoluer la bibliothèque standard : quoi y ajouter, quoi en retirer (ça arrive!), comment s'y prendre pour que le tout se passe bien, etc.

LWG

Library Working Group

Le groupe de gens qui cherchent à comprendre les problèmes existants dans la spécification existante de la bibliothèque standard, et qui visent à déterminer les correctifs optimaux dans chaque cas. Retenez que la bibliothèque telle que définie par le standard est une spécification, qui dit aux gens ce qui doit être fait, mais pas nécessairement comment le faire. Cela dit, les participants du LWG sont typiquement des gens qui implémentent la bibliothèque standard au quotidien

NAD

Not a Defect

Une préoccupation mise de l'avant par un document qui nous a été soumis est considérée, mais nous statuons qu'il ne s'agit pas d'un défaut

NaN

Not a Number

http://en.wikipedia.org/wiki/NaN

PDTS

Pre DTS

Un pré-DTS

SG

Study Group

Un paquet d'experts sur un sujet qui travaillent ensemble à faire avancer un dossier, en tout ou en partie, mais à titre exploratoire. Je fais entre autres partie de SG14, le groupe d'études pour ce qui a trait aux systèmes à basse latence

TS

Technical Specification

Un document qui ne fait pas officiellement partie du standard mais qui permet à tous d'expérimenter et de valider que les idées mises sur la table fonctionnent en pratique

WG

Working Group

Un paquet d'experts sur un sujet qui travaillent ensemble à faire avancer un dossier, en tout ou en partie. Notre groupe est WG21; les langage gens qui travaillent sur le langage C forment le groupe WG14, et il y en a plusieurs autres


Valid XHTML 1.0 Transitional

CSS Valide !