À propos de WG21, Issaquah 2016

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 à Éric St-Jean), 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.

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 environ 120.

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 en relief, 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

Au préalable

J'ai été sollicité par une firme de High Frequency Trading (HFT) d'Amsterdam pour donner une conférence sur la gestion des exceptions, semblable à ce que j'ai proposé à CppCon 2016, de même qu'une quinzaine d'heures de cours sur la programmation de systèmes à basse latence. Mon horaire n'offrant pas d'ouverture pour ajouter une telle prestation, j'ai adjoint ma présence à Amsterdam à celle à Issaquah pour WG21. Cette section porte donc sur la période de deux jours précédant mon arrivée à Issaquah, et ne concerne pas directement mon travail pour WG21 (quoiqu'il y ait des liens, évidemment).

La soirée du 1er novembre fut amusante mais pas reposante : je suis allé voir Marillion, un groupe important pour moi, donner une (excellente!) prestation au Corona à Montréal avec mon ami Jonathan Sawyer de même que mes deux plus jeunes filles, Amandine (quinze ans) et Vayda (neuf ans). Un autre bon ami, David Viens, devait venir avec nous mais sa santé lui a joué un tour. Une grosse soirée, avec beaucoup de route à faire pour transporter tout ce beau monde, mais un spectacle remarquable.

Puisque je devrais m'absenter de la maison pour un peu plus d'une semaine cette fois, j'ai fait de la lessive à mon retour à la maison (versh du matin), pour m'assurer d'avoir de quoi me vêtir. Il faut comprendre que la semaine sera chargée : voyager de Montréal vers Toronto, puis vers Amsterdam durant la nuit, arriver à Amsterdam le matin, aller faire un bref somme et prendre une douche, donner un cours, donner une conférence, dormir un peu, donner une journée de cours, dormir un peu et reprendre l'avions vers Seattle en vue de la rencontre du WG21. Il y a beaucoup à penser, et le temps est compté.

Après une courte nuit (un peu plus de deux heures de sommeil, à cause de tout ce qu'il y a à faire), un matin chargé avec une longue liste de tâches, en partie de la routine (transport des enfants, lunch, ordures, recyclage, compost), en partie en lien avec le voyage (bagages, s'assurer que mon arrivée à Amsterdam sera bien gérée) et en partie importante mais inhabituelle (paperasse pour faire abattre un arbre qui menace de tomber sur la maison, dû à l'action ravageuse de l'agryle du frène, ce qui devra être fait avant que les premières neiges ne tombent). Je suis allé embrasser ma belle Za avant d'aller à l'aéroport, où je me suis aperçu que j'avais laissé mon argent américain à la maison. Sans commentaire.

L'endroit où j'attends mon vol est un lieu que je n'ai pas encore visité dans l'aéroport, soit la porte la plus lointaine de toutes, située dans un joli secteur aéré, aux plafonds hauts, avec beaucoup de luminosité, des décorations proposées par le Musée McCord et le Musée d'Art Contemporain, un module de jeu pour les enfants, etc. J'ai profité de l'attente pour retourner mes (nombreux!) courriels en retard, car je cours tout le temps ces jours-ci.

Le vol de Montréal vers Toronto s'est fait sans événements particuliers, mais a été turbulent. On a cherché à me séparer de mon ordinateur portatif, mais puisque mon doctorat-sur-la-fin s'y trouve, j'ai résisté et on a trouvé une solution. On nous a servi un verre de vin et un petit gâteau banane-chocolat en chemin, mais le service a dû être interrompu à cause des turbulences susmentionnées.

À Toronto, j'avais peu de temps entre l'arrivée et le départ, et une bonne marche à faire, mais je suis arrivé en marchant d'un bon pas. Cependant, une fois rendu à mon point d'embarquement, nous avons vécu une attente de 35 minutes environ dû à un retard du vol qui arrivait pour nous cueillir. C'est là que j'ai vécu une expérience presque gênante : le traitement de classe affaires.

Avertissement : c'est de la grosse gâterie, et je ne pourrais pas me payer ça moi-même, mais les gens qui m'ont invité à Amsterdam m'ont payé ce luxe. Un peu comme je l'ai vécu dans un voyage première classe en train plus tôt cette année, mais avec un luxe nettement plus exacerbé, je me suis retrouvé dans une situation où j'ai l'air d'un éléphant maladroit dans un magasin de porcelaine, d'un poisson hors de l'eau, ajoutez la métaphore qui vous sied le mieux. Les grandes lignes :

Un peu de préparation en vue de tantôt, puis une petite sieste (il est maintenanth 46 du matin à Amsterdam). On nous apporte une bouteille d'eau et un verre pour la « nuit ». Je constate qu'Amsterdam est cinq heures « en avance » sur Montréal, alors que Seattle est cinq heures « en retard ». Bonjour le décalage horaire samedi quand je vais transiter de l'un à l'autre.

Nous avons tous un oreiller et une couverture, ce qui facilite le repos, mais le plus grand avantage de la classe affaires sur le reste de l'appareil, c'est la capacité de s'installer a l'horizontale. La journée qui vient sera difficile sur le plan physique, la nuit étant courte (et la précédente l'ayant été aussi, par la force des choses), mais sur le plan de l'état dans lequel mes hôtes me recevront, le luxe était peut-être un investissement.

Versh 30, heure d'Amsterdam, on rallume les lumières pour nous signaler la fin de la (courte) nuit de deux ou trois heures, et le service reprend :

J'ai écouté un peu de Marillion en pensant à ma fille Calypso et à son amoureux Brendon qui sont allés les voir à Québec pendant que j'étais dans les airs. J'espère qu'ils ont passé une belle soirée.


En arrivant à Amsterdam, les gens qui voyageaient en classe affaires sont débarqués en premier, autre expérience inhabituelle pour moi. Je suis passé aux douanes très aisément (c'est beaucoup plus simple de passer du Canada à l'Europe que de passer du Canada aux États-Unis), puis j'ai appelé le numéro de téléphone que l'on m'avait donné pour informer mon chauffeur que j'étais arrivé. Il est venu me cueillir pour m'amener à mon hôtel, un joli endroit avec une chambre étroite mais fonctionnelle.

Par contre, je suis arrivé à la chambre vers 10 h, heure locale, et le taxi me menant au lieu où je devais aller donner ma présentation devait venir me prendre vers 11 h 30. Ça ne me laissait pas assez de temps pour dormir, alors je me suis limité à prendre une douche. Ici, sans doute pour éviter les vols, il y a une distributrice de savon pour les mains près du lavabo de la salle de bains, et une distributrice de savon pour corps et cheveux dans la douche... mais ce matin, cette distributrice était vide, et je m'en suis rendu compte une fois sous la douche, alors je me suis lavé avec le savon à mains.

La ville est jolie, un peu à mi-chemin entre ce que j'ai vu en France et ce que nous avons vu Za, Cindy et moi en Finlande cet été.


J'ai eu un très bel accueil chez mes hôtes, et j'ai été « pris en charge » par Hashim Modhamed, un chic type qui est à l'origine de la décision de l'entreprise de m'inviter ici. Nous sommes allés bavarder un peu pour clarifier le plan de match de l'après-midi; nous avons aussi fait un petit tour des lieux, et nous avons mangé une bouchée à la cafétéria, très correcte d'ailleurs. J'ai goûté à une spécialité locale (hareng fumé et oignons crus), de même qu'à une soupe au curry, et je me suis prévalue de leur bar à salade.

Les installations sont correctes. J'ai un groupe d'un peu moins de quinze personnes, auxquelles s'ajoutent un petit groupe de participants à distance. J'ai donné le genre de cours qui a fait ma réputation, bonne comme mauvaise : un peu décousu, très à l'écoute des gens, enthousiaste. J'ai oublié de donner une pause, un classique. On poursuivra demain, bien sûr.


Vers 16 h, on aurait pu arrêter mais je leur ai offert de poursuivre un peu et nous avons convenu de tenir bon jusqu'à 16 h 30. J'ai utilisé le temps entre la fin du cours et l'accueil des gens pour ma conférence de la soirée pour écrire ceci, mais je suis fatigué alors il se peut que le texte ait besoin d'être retravaillé.

Quelques trucs pêle-mêle :

Vers 19 h 15, je suis allé manger une bouchée avec les participant(e)s de la soirée. On parle d'un peu moins de 70 personnes au total. Le repas était délicieux, un peu épicé, plusieurs viandes braisées, des oeufs cuits durs dans une sauce, des légumes cuits assortis. J'ai bavardé un peu avec l'un des employés de l'entreprise qui était dans ma classe en après-midi, un monsieur brillant d'origine roumaine qui habite en Roumanie mais travaille à Bruges, et fait l'aller / retour chaque semaine (il fait du télétravail cinq jours et du travail sur place deux jours).

Après avoir parlé un peu (surtout du refuge de chats de Za et Cindy, car j'ai inévitablement des tas de questions sur le sujet), je me suis déplacé au lieu de la conférence. Je parlerai devant le Dutch C++ Users Group, un regroupement local de programmeuses et de programmeurs. Les lieux sont accueillants, conviviaux : écran géant, fauteuils, bar, etc. Il y a un bruit de ventilation qui risque de me compliquer l'existence, mais on me dit qu'on pourra réduire son intensité quand je parlerai (si je dois parler « par-dessus », je n'aurai plus de voix demain). Christopher Lederer va accueillir les gens, puis je donnerai ma présentation et on prendra les questions. Il y aura une période de socialisation par la suite, mais le plan est de me sortir d'ici pour 22 h car je suis fatigué.

La présentation s'est bien passée. Christopher Lederer a fait une présentation générale de l'entreprise hôte, et Ray Burgemeestre (qui organise les événements du Dutch C++ Users Group) m'a présenté (il avait pris la peine de lire ma notice biographique et a fait un bon boulot). La salle était pleine, mes blagues et mes « mimiques » ont bien fonctionné, les gens ont ri, il y a eu plusieurs questions malgré ma voix qui s'étiolait, et j'ai eu beaucoup de questions aussi suite à la conclusion de la présentation. J'ai entre autres eu le plaisir de parler avec Carl Cook, un ami de SG14 avec qui j'échange souvent mais qui est venu me rencontrer en personne. Très chouette rencontre, un individu très agréable à côtoyer.

Je me suis ensuite permis une bière locale (gratuite, commerciale mais correcte), j'ai parlé un peu aux gens, puis Hashim Mohammed a eu la gentillesse de venir me chercher à 22 h. Nous sommes allés appeler le taxi, avons convenu d'une heure pour reprendre les opérations, et nous sommes retournés à la partie sociale de l'événement en attendant l'arrivée du taxi. Tout est payé par mes hotes encore une fois. Ray Burgemeestre m'a remis une petite bouteille d'un bon scotch en remerciement (j'en prends un verre en écrivant ceci; il est passé 23 h et je suis très fatigué).

Nous reprendrons les travaux tôt demain matin.


J'ai quand même dormi sept heures, donc pas mal plus qu'à l'habitude. Le déjeuner est fourni avec la chambre ici alors j'en ai profité. C'est une formule buffet, donc des trucs conventionnels, mais c'était bon et chaud, et les viennoiseries sont de qualité (toutes celles que j'ai goûté ici étaient chaudes et délicieuses). Le café est bon à Amsterdam, en général, mais les machines de type Nespresso prédominent. Je remarque qu'il y a du poisson (hareng ou saumon) à chaque repas jusqu'ici, et que les oeufs cuits durs et les noix sont mis en valeur à chaque repas; des messages sur les napperons et en périphérie des plats dans lesquels nous nous servions vantent les louanges des protéines (pas nécessairement animales).

Ayant dormi un peu plus que normalement, je vais essayer d'organiser ma journée avant de quitter l'hôtel, mais ce sera plus « serré » que je ne l'aurais souhaité.


Mon taxi était à l'heure. Grosse journée de travail; nous avons travaillé toute la journée, avec de brèves pauses pour fins biologiques sans plus, et on nous a servi le repas sur place (simple, des sandwichs, mais de bonne qualité). J'ai donné beaucoup, mais c'était un groupe de gens intéressants et intéresssés, et j'ai été bien traité du début à la fin. J'espère qu'ils ont apprécié.

Nous avons arrêté vers 18 h, et nous avions un repas sur un bateau vers 19 h en se promenant sur les flots dans la ville d'Amsterdam. Entre les deux, j'ai eu une visite du PDG de l'entreprise qui semblait de très bonne humeur, et nous avons bavardé une dizaine de minutes. Quelques personnes sont venues me poser des questions pendant ce bref intervalle de « pause », mais c'est correct – je ne suis pas là longtemps, alors aussi bien maximiser l'impact de la visite.

Le tour de bateau fut fort agréable. La ville est très belle, particulièrement la nuit, et les voies maritimes sont bien aménagées. Nous avons eu droit à un buffet de qualité, alcool, desserts, café, thé, tout cela à volonté, de même qu'à un excellent service. J'ai parlé politique (incluant Justin Trudeau, qui introgue les européens) et vie avec Christopher Lederer et Hashim Mohammed, deux personnes brillantes et dont la conversation est agréable, et j'ai pu voir la ville sous un jour très attrayant (faut comprendre que depuis mon arrivée, je ne l'ai à peu près pas vue, limitant mon temps à travailler beaucoup et à dormir un peu). Ne manquait que mon amoureuse Za, qui aurait beaucoup aimé je pense bien. Si vous passez par Amsterdam, je recommande l'expérience.

Vers 21 h, nous avons été ramenés à notre point de départ, près du lieu où se situe l'entreprise, et un taxi est venu me chercher pour me ramener à l'hôtel. Bonne chose car je dois dormir un peu, devant prendre le taxi versh 30 demain matin – je dois prendre l'avion puis traverser huit fuseaux horaires et m'amener à Seattle.

Jour -2 5 novembre 2016

Debout versh du matin, douche, paqueter mes trucs (chose facile à faire, honnêtement, car je ne me suis pas étalé étant donné le peu de temps passé ici et le rythme un peu dément de mon passage). Techniquement, j'ai droit au déjeuner fourni avec la chambre, mais en pratique il n'est servi qu'àh la fin de semaine, et mon taxi doit me cueillir àh 30. Par contre, j'ai parlé un peu avec les gens à l'accueil hier soir et ils m'ont laissé entendre que je pourrais accrocher une bouchée àh 30 car l'essentiel du déjeuner est déjà prêt à cette heure, alors on verra.

Je me sens un peu mal : la tradition veut que l'on laisse un petit quelque chose pour les gens qui assurent l'entretien de la chambre, mais je n'ai pas de monnaie du tout sur moi.

Arrivé au lobby, j'informe les gens de mon départ, je prends une petite viennoiserie pour la route (on mangera bien dans l'avion, étant donné les conditions exceptionnelles qui m'ont été offertes par mon hôte, mais c'est dans quelques heures) et je sors quelques minutes en avance sur l'horaire. Mon taxi est déjà là. Il se trouve que la route vers l'aéroport est se fait sans le moindre anicroche : les chemins sont d'excellente qualité, beaucoup d'infrastructures sont neuves, et le trafic est inexistant ce matin. Ce que je retiendrai d'Amsterdam : c'est joli, l'architecture est intéressante, les gens sont gentils et il est très facile de fonctionner pour un étranger. Si vous voulez de la bière, mieux vaut apprécier la Heineken car les produits de cette brasserie (locale) prédominent nettement, du moins dans les endroits où je suis allé (la situation est sans doute différente si on se promène un peu; Amsterdam, c'est quand même une ville de plus d'un million d'habitant(e)s).

L'expérience à l'aéroport est particulière. C'est évidemment un très bel endroit pour l'essentiel, du moins dans les premiers du trajet (c'est plus négligé là où se fait l'embarquement), mais je ne suis toujours pas habitué au traitement « classe affaires », où tout est plus facile. L'accueil de base est simple et rapide (on ne me pose à peu près pas de questions). Ici, pour la fouille, pas besoin de retirer ses souliers (à moins qu'ils ne couvrent la cheville), pas besoin non plus d'enlever sa ceinture, mais il faut sortir de nos sacs tout câble ou fil électrique. On me fouille coimme c'est souvent le cas car mes cheveux, épais, laissent croire aux détecteurs que je porte du métal sur les omoplates. C'est un classique.

Une fois rendu à la « porte » D1, sorte de « méta porte » par où doivent passer les voyageurs en direction des États-Unis, je passe une entrevue piège avec un agent qui cherche par toute sorte de moyens à savoir si j'aurais pu laisser mes bagages hors de ma vue, ou si quelqu'un aurait pu y glisser quelque chose, ou si j'ai reçu un cadeau d'un inconnu... Est-ce parce qu'Amsterdam a une réputation de permissivité envers les produits du chanvre? Mystère. Je redoute un peu le traitement auquel j'aurai droit à mon arrivée aux États-Unis.

À ma porte d'embarquement réelle, pas de prise de courant. Il y a des prises de courant au Starbucks non loin, mais elles sont occupées. Je m'installe quelque part non loin et je travaille sans alimentation électrique, mais c'est agaçant car je ne peux pas travailler avec alimentation électrique dans les avions (ma pile est trop exigeante), ce qui fait que l'énergie dépensée ici est bêtement perdue. J'ai un long trajet devant moi, ce serait bête de ne pas en profiter un peu pour faire avancer mes dossiers. Heureusement, une place finit par se libérer et je peux travailler dans des conditions plus raisonnables. J'ai énormément de documents à lire d'ici lundi, et j'aimerais bien finir mon doc que je devais livrer avant de partir, mais que les événements ont bloqué (c'est urgent...)

Je volerai sur Delta cette fois. J'ai vécu l'expérience « luxe » KLM pour l'aller; je suis curieux de comparer, dans la naïveté la plus totale, les moeurs de deux entreprises. Je vais sans doute encore avoir l'air d'un clown perdu, mais bon, assumons-nous...


J'ai été questionné à nouveau avant d'entrer dans l'avion, à savoir si j'avais laissé mes sacs hors de ma vue ou si j'avais laissé un tiers les manipuler. C'est une question qui semble prise au sérieux ici. Par contre, le fait que j'aie un passeport canadien m'a permis d'éviter de la paperasse que d'autres doivent remplir avant d'entrer aux États-Unis.

La section « affaires » de mon avion cette fois est très confortable, mais moins spectaculaire que lors du voyage de Toronto à Amsterdam (où la section ressemblait plus à un salon chic). Encore une fois, des sièges confortables, de grands écrans (mobiles!) et des sièges qui se transforment en véritables lits sans déranger les autres voyageurs, mais dans des espaces un peu plus exigus. Par contre, ces espaces sont bien aménagés et plus intimes, ce qui n'est pas déplaisant. Aussi, j'ai cette fois droit au hublot, ce que j'aime bien. Les rituels « chics » comme la distribution de débarbouillettes chaudes, le service ultra-personnalisé, la nappe et la coutellerie, les petits accessoires (des salières et poivrières en forme de petit dé, par exemple) rappellent ceux du voyage me menant à Amsterdam, mais avec leur personnalité propre.

On nous a cette fois encore offert un verre à l'arrivée, et j'ai accepté le champagne cette fois. Plutôt que d'avoir une série de services nous offrant un cadeau, des grignotines, de l'eau, etc., chaque siège était déjà organisé de manière à ce que ces trucs soient prêts. Une boutelle d'eau (belge), des noix (pacanes sucrées et piquantes; Za, pas ton genre mon amour), oreiller, couverture, un petit cadeau (un étui pour appareils électroniques), ce genre de truc. On nous a rapidement consulté, en nous appelant par notre nom, pour connaître nos préférences alimentaires. Puisque le trajet durera plus de dix heures (pratiquement dix heures et demie, en fait), un repas est servi au début, un autre à la fin, et des biscuits chauds aux pépites de chocolat seront servis à peu près à mi-chemin.

Nous avions deux entrées. La première était faite de tois petites tranches de canard fumé glacées miel et thym, servies sur un lit de patates douces blanchies et croustillantes, accompagnées d'une purée de betteraves et de fruits (ça goûtait la bonne confiture) et d'une mixture de figues et de moutarde de dijon. La seconde était une salade d'épinards, noix et copaux de parmesan, accompagnée de quartiers de khakis, avec en option (que j'ai prise, et c'était une bonne idée) un petit bol de potage au panet, chaud et succulent. Pour le repas principal, des trois options offertes (les autres étant un ragoût et un poisson; les deux étaient alléchantes), j'ai choisi un risotto aux champignons, l'option végé, et c'é.tait vraiment délicieux (cuisson parfaite). Chaque plat était une petite portion seulement, ce qui est excellent dans les circonstances. Le vin était de qualité (et à volonté, comme c'est le cas dans ces conditions) et le café était très correct. Pour dessert, il y avait de la crème glacée, un gâteau chocolat et pacanes, et une petite assiette de fromages (ce que j'ai pris, et ils étaient franchement bons : un Montero, un Morbier Royal et une Fourme d'Ambert, le tout avec quelques raisins et de la confiture d'oignon).

J'ai travaillé un peu par la suite, puis j'ai piqué un somme en écoutant un peu de musique...

Une fois réveillé, à peu près à mi-chemin, j'ai profité du biscuit chaud avec un café, et j'ai travaillé une heure environ. Ma pile ne se rechargeant pas en avion (l'alimentation électrique est insuffisante pour mon ordinateur), j'ai dû m'arrêter après un certain temps. J'aurais pu faire un somme à nouveau mais je me suis laissé prendre à un jeu de logique sur l'ordinateur de bord et ça m'a permis d'écouler le temps en me divertissant un peu. Un goûter léger mais de qualité a suivi, un peu plus d'une heure avant l'atterrissage (de petis satays de poulet, une moutarde créole, une salade de légumes légèrement marinés, un peu d'orzo croquant, des fruits, un chocolat fin, le tout avec un verre de rouge). L'air de rien, c'est un long trajet, mais le privilège de voler dans un contexte comme celui dont je profite cette fois rend le tout très confortable. J'ai pris le temps d'aller remercier la chef pour son excellent travail.

Je viens de réaliser que mon hublot ne sera pas du bon côté de l'avion pour me permettre de contempler le spectaculaire Mont Rainier quand nous serons tout près de Seattle (on le voit bien à gauche, mais je suis assis du côté droit cette fois). Eh ben.

J'ai pris le reste du vol, du moins la partie où c'était possible (car il faut ranger nos outils de travail lorsque la descente est débutée) pour faire des retouches sur ma thèse.


À l'arrivée à Seattle, j'ai retrouvé mes bagages (ça a pris plus d'une heure), passé quelques contrôles; il s'agit d'une chose relativement facile pour un détenteur de passeport canadien, mais il y a de nombreux points de contrôle pour les bagages. J'ai d'ailleurs compris un truc qui m'avait frappé en arrivant à Amsterdam : plusieurs gens emballent leurs valises avec des pellicules de plastique (à la Dexter, pour celles et ceux qui ont suivi cette série télévisée), mais je pense que c'est pour éviter que des gens y insèrent des objets sans leur consentement. À l'oeil, presque une personne sur trois, à l'arrivée à Amsterdam et à l'arrivée à Seattle en provenance directe d'Amsterdam, avait emballé ses bagages comme cela. J'ai parlé par Skype à Za et aux enfants en attendant, puis j'ai trouvé mon chemin jusqu'à un taxi, qui m'a mené à mon hôtel pour la semaine.

Une fois arrivé à l'hôtel, j'ai fait mon Check-In et j'ai trouvé ma chambre. Il était environ 15 h (je suis arrivé plus tôt mais avec les délais de récupération de bagages et le transport, qui a pris une bonne demie-heure...) et je ressentais un peu le décalage horaire. J'ai encore une fois parlé à ma belle Za et aux enfants, puis j'ai constaté... que je n'avais plus de fonds. Je savais que je serais « serré » cette semaine, mais l'hôtel a pris plus en « protection » sur ma carte que ce à quoi je m'attendais, et le taux de change étant ce qu'il est... Alors j'ai passé une heure avec ma banque et ma compagnie de crédit au téléphone pour trouver une solution, au moins pour la semaine. Stress inutile, mais bon : j'ai des fonds présentement, suivant la classe que j'ai donné à CppCon 2016, mais ils sont gelés pour quelques semaines encore car ils ont été versés en agent américain, longue histoire.

Ensuite, j'ai simplement lu un peu et je me suis endormi vers l'heure du souper ici, en écoutant le début du match du Canadien contre les Flyers à la radio par Internet.

Jour -1 6 novembre 2016

Réveillé versh du matin, heure locale (tenant compte du changement d'heure, qui s'est fait cette nuit). J'ai regardé mes courriels, parlé un peu à Za et à Ludo, qui se sont levés tôt, constaté que ma grande Marguerite m'a envoyé une recommandation cinématographique, puis regardé brièvement quelques trucs en lien avec les élections américaines (je vais être ici pendant que ça se passe, après tout, même si je ne crains pas de violence étant donné le groupe avec lequel je travaillerai). J'ai fait ma toilette, me suis rasé, ai (enfin!) pris une douche, puis j'ai fait l'inventaire des vêtements propres qu'il me reste après le tourbillon des derniers jours; constatant que ce serait un peu juste côté bas et sous-vêtements, j'ai regardé les frais de lessive à l'hôtel et j'ai décidé de les laver moi-même, dans le bain (un bon 100 USD+ d'épargné; les frais de lessive des hôtels sont absurdes). Le tout est installé sur un séchoir non-loin de moi maintenant.

Le plan de match pour aujourd'hui est de profiter du déjeuner gratuit (car le reste de la journée sera frugal), puis de préparer ma semaine (beaucoup, vraiment beaucoup à lire) et utiliser le temps qui restera pour ma thèse.

Je suis allé à l'accueil pour valider que j'avais bel et bien droit au déjeuner ce matin, comme l'indiquaient mes courriels, car la dame qui m'a accueilli hier ne le savait pas. Pour aujourd'hui, il faut un coupon, que le charmant monsieur m'a offert. Pour ce matin, étant dimanche, le déjeuner est en formule « brunch » alors je vais y aller un peu plus tard pour gérer ma journée intelligemment. J'ai aussi constaté que ma chambre contient une machine à café format portions individuelles (style Keurig), alors j'en ai profité pour valider que son usage est sans frais, et que je pourrai aller chercher des capsules à l'accueil au besoin; c'est bien le cas. Ce sera utile aujourd'hui. On a bavardé sur les élections américaines; il n'a jamais nommé qui que ce soit, mais il est clair qu'il était étonné que les gens hésitent entre élire une personne expérimentée et compétente et élire... quelqu'un d'autre (c'est pas mal ses mots). Il m'a parlé beaucoup de la colère des gens envers le gouvernement et tout ce qui s'y rattache, ce qui est probablement un élément clé d'information pour les étrangères et les étrangers comme moi pour qui ces élections un peu kafkaesques sont difficiles à déchiffrer.

Après avoir travaillé un peu, en écoutant La soirée est encore jeune d'hier soir (je suis un fan fini, désolé!), je suis allé manger une bouchée versh, heure locale. En examinant la procédure pour manger (on se sert, mais pas pour les trucs chauds; dans ce cas, c'est les gens du restaurant qui offrent le service, alors c'est pas à volonté), j'ai croisé Lisa Lippincott avec qui j'ai eu le plaisir de partager une heure, pour discuter de ses théories et de ce qu'elle cherche à amener comme rigueur dans le langage. J'ai été gâté; c'est une personne brillante et sympathique. J'ai dû m'excuser après une heure car j'ai énormément à faire, mais je suis bien content qu'elle soit parmi nous cette semaine.

Le reste de la journée est simple : lire, prendre des notes, lire, et prendre des notes. Un peu de café ici et là, et le bonheur de parler un peu avec Za (et un peu moins avec Ludo, qui est grognon aujourd'hui apparemment). Pendant l'après-midi, on a appris que les courriels d'Hillary Clinton étaient une banalité; étranges élections que celles-ci. Un peu plus tard, ma grande Marguerite m'a lâché un petit coup de fil par Skype; c'est toujours chic de voir un peu les enfants malgré la vie qui est un peu (beaucoup!) folle. J'ai mis Tout le monde en parle en arrière-plan, mais à la radio seulement car, pour des raisons mystérieuses, Radio-Canada ne permet pas que je regarde les images quand je suis hors du pays (http://ici.tou.tv/ non plus, d'ailleurs). Aucune idée pourquoi; c'est pas comme si c'était bien menaçant. J'ai reçu quelques messages m'apprenant que je vais diriger de nouveaux étudiants à la maîtrise; je me trouverai un moment pour les rencontrer à mon retour.

Je suis sorti prendre une marche en début de soirée. En croisant un collègue qui habite en Oregon, l'État voisin, j'ai appris que chez lui, le vote se fait par la poste, et qu'il a voté il y a plus d'un mois. Il se trouve qu'il n'y a même pas de bureaux de vote chez lui. Il était sorti en après-midi et avait trouvé une épicerie non-loin, alors je suis allé me chercher un peu de vin, une salade, des pommes et quelque chose à grignoter en travaillant. Au retour à l'hôtel, en quelques secondes, j'ai croisé Titus Winters, Chandler Carruth, Alisdair Meredith et d'autres, signe que tout est prêt. J'ai mis quelques heures sur ma thèse, parlé à mon amoureuse Za, et fermé les yeux pour quelques heures. Demain, la folie commence.

Jour 0 7 novembre 2016

Après m'être levé versh 30 heure locale (pour parler un peu à mon amoureuse et aux enfants), j'ai pris une douche, me suis fait un café, et j'ai examiné le plan de travail des divers groupes d'étude cette semaine. Il faut comprendre ici la mécanique normale d'une semaine de travail avec WG21 (voir https://isocpp.org/files/papers/N4608.html pour une vision de haut niveau) :

Déjeuner format buffet, de bonne qualité. Je mange un peu, remercie Thomas Köppe pour sa merveilleuse idée de permettre de déclarer et d'initialiser des variables dans un if et dans un switch (quelle coup de génie, vraiment; simple, efficace, rend tout le monde heureux), j'échange un peu avec Peter Sommerlad sur la politique de la semaine qui s'annonce, je bavarde un peu avec Loïc Yvonnet qui est venu par intérêt (il n'a pas de proposition cette fois et n'a pas droit de vote), et j'ai une discussion avec Walter E. Brown sur <random> et les travaux sur une éventuelle TS dans ce créneau.

J'ai profité de la présence de Walter E. Brown pour valider quelques trucs, notés ici pour mes étudiant(e)s et pour ne pas les oublier moi-même :

Jonathan Caves est venu me serer la main et me saluer en français. Quel individu adorable! Louis Dionne est parmi nous (JF Bastien m'a fait remarquer que notre délégation canadienne est désormais à un tiers francophone, ce qui est amusant). J'ai eu quelques échanges avec les amis Billy Baker et Hubert Tong en vue de la politique de cet avant-midi. Nous aurons des votes à prendre et ces votes influenceront notre semaine, sans parler du futur du langage, l'air de rien, et l'un des votes clés est exprimé sous la forme suspecte de « avez-vous assez étudié l'élément XYZ pour le refuser et de manière telle que rien cette semaine ne vous ferait changer d'idée? », ce qui est une drôle de formulation. En attendant que nous commencions les travaux Billy Baker (qui oeuvre dans le monde des simulateurs de vol, que je connais bien) me racontait des histoires de travail décourageantes...

Clark Nelson prend la parole àh, accompagné de Herb Sutter. Herb Sutter, notre hôte cette semaine, nous informe que le dîner sera fourni., une bonne nouvelle pour moi étant donné mon budget « surprise » de la semaine. On nous explique la mécanique des salles de travail. Clark Nelson fait un rappel des règles du jeu et du code d'éthique en vigueur. Il y a des changements dans les règles de participation pour les délégués américains (un vote par compagnie, pas un vote par personne, du moins en plénière). Dans les groupes de travail, où l'on tient des Straw Polls d'experts, on y va à une personne, un vote. Pour les gens dans le bottin ISO, comme moi, c'est une personne, un vote. John Spicer rappelle les procédures de prise de présence (on ne signe qu'une fois dans la semaine, c'est suffisant, à moins que l'entreprise envoyant un individu ne souhaite une signature pour chaque jour).

On fait le tour des présentations. On est un bon groupe; plus de 120 aujourd'hui, à l'oeil. Le plus amusant était Michael Wong, qui vient de changer de boulot et s'est presque trompé en mentionnant son employeur (on a bien ri). Herb Sutter dit avoir compté dix pays, soit les États-Unis, la Grande-Bretagne, l'Espagne, la Finlande, le Canada, l'Allemagne, les Pays-Bas, la Bulgarie, la Russie et la Suisse. C'est une belle représentation.

On examine l'ordre du jour. Mike Miller demande quel est le statut de la proposition sur les coroutines. Clark Nelson dit qu'il lui semblait possible de faire avancer ce dossier cette semaine. Herb Sutter dit que c'est lui qui a oublié de le mettre à l'ordre du jour, mais que les NB Comments ont la priorité. L'ordre du jour est adopté en incluant les coroutines.

Clark Nelson mentionne ensuite que nous avons quatre WD à examiner (le standard de C++ en soi, puis Library Fundamentals v2 TS, Modules TS et Networking TS). On approuve les WD. Peter Sommerlad demande si on pourra ajouter autre chose à ces documents cette semaine, mais Herb Sutter dit qu'on y reviendra plus tard. Richard Smith mentionne que WG motion 13 n'a pas été appliqué au standard encore, mais qu'il y a un NB Comment pour l'appliquer cette semaine. On approuve ensuite les minutes des rencontres précédentes, en particulier celles de la rencontre à Oulu. Ça se fait sans heurts.

Herb Sutter mentionne les priorités de la semaine : les NB Comments pour le CD de C++ 17, et la progression de Library Fundamentals TS v2. Aussi importants, mais à un moindre degré, les WD des Modules, Ranges, Networking, Parallelism v2 (tous à avancer à PDTS) et Concurrency v2 (avancer à NP). Mike Spertus demande si Library Fundamentals v2 est Feature-Complete. Herb Sutter dit qu'à moins d'une explosion spectaculaire, c'était Feature-Complete en sortant de Kona.

La feuille de présences passe et, cette fois, j'existe!

Ensuite, on fait le tour des plans de match des groupes de travail. On apprend au passage que Michael Wong remplacera Ville Voutilainen à la tête d'EWG ce matin car ce dernier a des problèmes d'avion (il devrait être là cet après-midi). On le savait déjà, mais Neil MacIntosh remplacera Jeffrey Yasskin à la tête de LEWG, mais pour la semaine entière dans ce cas. Marshall Clow indique que <filesystem> prendra beaucoup d'énergie chez LWG, mais il dit ne pas être certain qu'il aura recours à des sessions de soirée cette fois car les journées vont être lourdes. Alisdair Meredith demande quelles sont les probabilités de mener le Networking TS au stade de PDTS cette semaine; ; Marshall Clow pense que c'est possible, car des progrès ont été faits à Chicago dans une rencontre spéciale s'étant tenue entre Oulu et maintenant. Neil MacIntosh a un plan de match pour LEWG connexe à celui de LWG. Mike Miller dit que CWG en aura plein les bras juste à traiter les NB Comments, et profitera du fait que Jens Maurer et Ville Voutilainen ont fait un tri sur ces commentaires pour faciliter la répartition du travail. Quelqu'un demande comment on fait le choix entre LWG et LEWG pour un dossier, et Neil MacIntosh dit que ça se discute d'abord entre lui et Marshall Clow pour voir s'il y a un élément évolutif ou non.

Vient ensuite la question des votes pour fins d'addition ou de suppression de changements d'éléments à C++ 17. Herb Sutter dit que les seuls changements acceptables sont ceux qui accroîtraient le consensus :

Ceux qui sont donc encore sur la table sont la génération automatique d'opérateurs de comparaison, les « conversions élémentaires » de/ vers des string, la suppression des spécifications dynamiques d'exceptions et l'ajout tardif de std::byte.

On examine ensuite la gestion des salles de rencontre, pour être en mesure d'accommoder le nombre de participant(e)s dans chaque cas. On est pas mal nombreux. Beman Dawes fa fait remarquer que LWG se séparera en deux groupes ou plus, alors ils ont besoin d'un peu d'espace. Herb Sutter fait remarquer qu'on peut utiliser d'autres espaces que les salles de rencontre prévues, par exemple le restaurant qui ne sera pas utilisé pendant les périodes de travail.

Les dîners iront de 12 h à 13 h, mais vendredi, le travail post-dîner débutera à 14 h 30 (pour que les gens à la tête des groupes de travail aient le temps de s'organiser). Pour les séances de soirée, de 20 h à 21 h 30, on planifie ce qui suit :

Ce soir, il y aura une rencontre de la C++ Standards Foundation mais c'est autre chose et ce n'est pas officiellement lié à WG21. Ce sera à 17 h 30.

On prend une brève pause pour se déplacer dans les différentes salles, et d'organiser les salles. La pause se tient à 10 h 15. Je me déplace vers la salle de CWG pour retrouver ce groupe sympathique avec qui c'est agréable – et très perturbant, dans un sens amusant – de travailler.

Ce matin, en l'absence de Jens Maurer (problèmes d'avion), je tiendrai le Wiki à jour de mon mieux, alors mes notes seront fragmentaires.

Sont présents à CWG : Jonathan Caves, Davis Herring, Maxim Kartashev, Thomas Köppe, Jens Maurer, Jason Merrill, Mike Miller, Christopher Mysen, Gor Nishanov, Roger Orr, Michael Price, Dinka Ranns, moi-même, Richard Smith, John Spicer, Hubert Tong, Faisal Vali et Vassil Vassilev.

Mike Miller présente la procédure pour le début de la semaine, soit traiter les NB Comments concernant CWG dans l'ordre où ils apparaissent.

Dans ce qui suit, les commentaites sont par pays. ES signifie Espagne, US signifie États-Unis, GB signifie Grande-Bretagne, JP signifie Japon, FI signifie Finlande, RU signifie Russie, CA signifie Canada

ES3

On convient que l'exemple devrait utiliser constexpr dans la déclaration de la variable. On parle d'une const int à laquelle on affecte une constexpr int. D'accord.

US4

La demande est de remplacer des ::value par des _v. Richard Smith suggère que ceci puisse être superflu pour fins de discussion du Core Language. Une discussion s'ensuit, et la proposition est rejetée

US28

Hubert Tong suggère d'attendre l'arrivée de Jens Maurer qui a une résolution à proposer. Richard Smith pense qu'on peut simplement accepter les changements terminologiques proposés par Jens Maurer wording. Accepté

US72

La problématique soulevée touche au rôle de unsigned char.

US87

Cette proposition touche la terminologie utilisée pour définir les garanties de progression (Progress Guaranteees) des algorithmes parallèles

US96

Passer une notation de « basée 1 » à « basée 0 ».

US98

L'extension de la durée de vie des temporaires semble ne pas fonctionner pour un cas tel que :

auto [x,y] = std::make_pair("hello", "world");

US103

On parle du recours à un guide de déduction pour un vecteur, mais le texte ne semble pas assez clair pour ce qui est de l'allocateur et on réclame un exemple.

US166

Le commentaire mentionne que les limites inférieures décrites dans le langage C sont souvent plus basses qu'en C++, et suggère que l'annexe C, qui décrit les différences entre les langages, en parle un peu

GB1 et JP1 (même commentaire dans les deux cas)

GB5

Critique de la faiblesse de la définition du terme template parameter

GB6

La critique est subtile :

The definition of undefined behavior does not allow for the requirement that 'constexpr' functions are required to diagnose undefined behavior in constant evaluation contexts. This also affects what we say for SFINAE: you get a substitution failure if the substituted type *would be* ill -formed (but you don't actually form it in that case, so the program is not ill -formed); you get a non-constant expression if the evaluation *would have* undefined behaviour (but you don't actually evaluate it in that case, so the behaviour is not undefined).

La clé est qu'il faut un texte qui ne force pas le compilateur à générer des structures incorrectes.

GB7

Un exemple accompagné d'un peu de texte entraîne de la confusion dans un cas de chevauchements de zones mémoire.

GB8

GB9

Le commentaire discute de la manière sont décrites les classes vides qui servent de parent et se prêtent à EBCO.

GB13

GB14

GB15

Ce cas vise du code comme :

auto f(int &r) {
    return [&]{ ++r; };
}
void g(int n) {
   f(n)();
}

...qui semble être du comportement indéfini selon le textre proposé pour le standard, alors que c'est techniquement correct.

GB19

Ce qui suit était correct auparavant mais semble brisé selon le texte proposé :

const int &r = 1; 
constexpr int n = r; 

GB23

On a un cas où des gens pourraient essayer de faire ceci :

template <typename T>
   void test() { 
      try { 
         T t = {}; 
         throw t; 
      } catch(T const &) {
      }
   }
// ...
test<int[8]>(); // l'exception, un int*, ne sera jamais attrapée

... mais que ça n'a pas de sens cas il est impossible que le catch fonctionne dû à la décrépitude de pointeurs (le tableau devient un pointeur car il est levé par valeur).

GB24

GB25

GB26

Que fait quand, par get_exception_ptr(), deux threads traite nt concurremment un même objet d'exception?

GB63, GB64 et GB65

Respectivement, quelle est la limite inférieure à supporter pour un compilateur pour (GB63) le nombre de paramètres à capturer dans une λ,(GB64) le nombre d'expressions séparées par des virgules dans une liste d'initialisation, et (GB65) le nombre de variables dans une expression de décomposition (Structured Binding)?

Petite pause pour dîner : poulet, légumes grillés, pâtes végétariennes farcies, pain, salade. Très correct. Je bavarde un peu avec Lisa Lippincott, qui me dit être d'avis que dans une levée d'exceptions, le type importe moins que le lieu de sa levée. Je ne suis pas d'accord, alors on échange des idées. Pour des raisons évidentes de budget, je profite de ces repas à plein. On mange en travaillant parce qu'on a les mains pleines (techniquement, on est en pause, mais c'est un feu roulant depuis le début et j'ai des courriels d'étudiant(e)s / de département / syndicaux à retourner). On a une visite de Clark Nelson qui veut vérifier si un sujet (je n'entends pas lequel) est à l'ordre du jour, de Michael Wong et de Gor Nishanov qui passent dire bonjour, puis de Gabriel Dos Reis qui nous informe que l'un des groupes d'étude suggère de « tuer » les Deduction Guides, ce qui me surprend un peu (c'est un truc chouette, même s'il y a des détails à roder). On en parlera sûrement plus tard cette semaine.

Jens Maurer n'est pas revenu à 13 h alors je conserve le Wiki. Il arrivera vers 14 h 30 environ, mais je garderai le fort du Wiki jusqu'à la pause de 15 h 15.

RU1

Avec le texte tel que proposé, on a ces situations étranges avec les classes vides :

struct A0 {};
const A0 a0; // ill-formed
struct A1 {
    A1(){}
}; 
const A1 a1;
struct A2 {
    int i;
    A2(): i(1) {}
}; 
const A2 a2;
struct A3 {
    int i = 1;
}; 
const A3 a3; // ill-formes

JP2

JP3

JP4 et JP5

JP6, JP7, JP14, JP16 and JP17

JP8

JP10 et JP11

JP12

JP15

JP18

CA12

Que faire avec ceci?

#include <new>
int bar() {
   alignas(int) unsigned char space[sizeof(int)];
   int *pi = new (static_cast<void *>(space)) int;
   *pi = 42;
   return [=]() mutable {
      return  *std::launder(reinterpret_cast<int *>(space));
   }();
}

Mike Miller : EWG nous a relayé quelques dossiers

US101

Éliminer le terme POD du standard, car il est sous-spécifiéé

GB20

GB68

P0057R6 Wording for Coroutines (Gor Nishanov)

Petite pause vers 15 h 15. Les gens sont de bonne humeur, Gor Nishanov n'est pas trop déprimé malgré le travail fait et à faire, il y a de petits brownies et des fruits à titre de collation. Za m'informe par Skype qu'elle a eu une crevaison; pour faire exprès, elle était avec ma petite Kia Rio, dont j'ai acheté les pneus neufs juste avant de partir pour Amsterdam. Son papa, le très chic Jocelyn, est venu l'aider (un gros merci, cher ami!)

On reprend vers 15 h 35.

Jens Maurer demande une précision sur la durée de vie des variables. Gor Nishanov précise. Jens Maurer est rassuré.

Mike Miller demande si on a encore des suggestions à faire pour Gor Nishanov. Gor Nishanov demande si on doit conserver des marqueurs de modifications dans le document. Mike Miller dit oui, mais en comparaison avec le document actuel.

Mike Miller suggère que l'on examine les recommandations terminologiques de Jens Maurer en lien avec les dossiers traités ce matin.

On les prend un à un dans D0490R0: Core language changes addressing National Body comments for CD C++17

US28 : incorrect definition for principal constructor

Mike Miller : il y a eu des échanges à propos des Principal Constructors.

Hubert Tong : j'aime ce qu'a proposé Jens Maurer, mais j'aimerais quelque chose de plus agressif.

Mike Miller : Bjarne Stroustrup semblait d'avis que ce choix de mot pourrait confondre des gens venant d'autres langages

Jens Maurer : on peut dire ça de beaucoup de choses avec C++

Richard Smith : le terme n'apparaît qu'à quelques endroits et semble signifier « un constructeur », alors il ne vaut probablement pas la peine de le conserver.

Jens Maurer : dans un cas d'objet Value-Initialized ou Aggregate-Initialized, il n'y a même pas de constructeur

Hubert Tong : on a de la terminologie wishy-washy dans ce coin-là.

(on cherche un terme comme non-delegating constructor; ce qui agace Jens Maurer est que ça laisse entendre qu'il existe un constructeur alors, et c'est pas toujours vrai)

US103 :

Mike Miller : faudrait un exemple.

Jens Maurer : en voilà un :

template<class T, class D = int>
   struct S { };
template<class U>
   S(U) -> S<typename U::type>;

Faisal Vali : faudrait ajouter un cas d'utilisation du type S par la suite.

Jens Maurer : Ok, je vais faire ça.

GB5 : definition of template parameter

C'est une simple définition manquante. Ce qui est proposé semble pas mal.

Hubert Tong : peut-on changer template pour template name?

Richard Smith : peut-on changer prvalue pour value or reference?

John Spicer : il y a trois catégories de paramètres, pas une sorte de paramètre avec trois noms.

Richard Smith propose une formulaton qui semble pas si mal.

Hubert Tong : peut-on utiliser placeholder, puisqu'on n'a pas encore de nom à ce stade? Le nom apparaît plus tard...

GB6 : definition of undefined behavior vs. constexpr

Richard Smith : on souhaitait unifier un peu les concepts de comportement indéfini en cas de constexpr et de « malformé » pour clarifier le fait qu'on ne se rend jamais au point où on générerait quelque chose d'incorrect.

Jason Merrill : on veut simplement une note

Le texte proposé est :

undefined behavior

behavior for which this International Standard imposes no requirements, except as specified for the evaluation of constant expressions (5.20 [expr.const]) [ Note: Undefined behavior may be expected when this International Standard omits any explicit definition of behavior or when a program uses an erroneous construct or erroneous data. Permissible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during translation or program execution in a documented manner characteristic of the environment (with or without the issuance of a diagnostic message), to terminating a translation or execution (with the issuance of a diagnostic message). Many erroneous program constructs do not engender undefined behavior; they are required to be diagnosed. -- end note ]

Hubert Tong : la seule définition de « malformé » pour l'instant parle du programme entier. Il faudra élargir légèrement la définition.

GB9 : base class object of zero size

Jens Maurer : je me limiterais à dire qu'il est possible qu'une telle base pourrait avoir la même adresse que l'objet englobant ou d'autres objets englobés.

Hubert Tong : j'ajouterais qu'un tel objet a une représentation distincte de celle qu'il a lorsqu'il est utilisé en tant que lui-même. Je pense qu'on a déjà une terminologie générale qui fonctionne, et qu'on ne devrait pas s'en faire avec des cas particuliers de plus.

John Spicer : à mon sens, ce qui est vraiment intéressant est le possible partage d'adresse

Richard Smith : ce qu'on devrait vraiment mettre en valeur est que l'espace peut être réutilisé pour d'autres sous-objets. Deux objets dont la vie se chevauche ne peuvent se chevaucher que...? On a même un passage qui donne des restrictions sur memcpy() à 3.9p2 :

For any object (other than a base-class subobject) of trivially copyable type T, whether or not the object holds a valid value of type T, the underlying bytes (1.7) making up the object can be copied into an array of char or unsigned char.42 If the content of the array of char or unsigned char is copied back into the object, the object shall subsequently hold its original value

Hubert Tong : je pensais à §5.3.3p2 mais c'est plus ou moins bien écrit. Rien dans une classe n'en fait un most-derived on non.

Richard Smith : notre terminologie existante ne rend pas claire le fait que le premier attribut d'un objet peut être dans un de ses sous-objets.

Hubert Tong fait remarquer que plusieurs compilateurs gèrent mal le Zero-Initialization dans des cas de constructeurs de délégation.

Hubert Tong travaillera la terminologie. Richard Smith recommande qu'on ajuste aussi une note en bas de page suspecte. Hubert Tong va essayer de faire converger les références à des Zero-Sized Subobjects vers un même point. Richard Smith pense que ça enlèvera un peu de côté « spécial » des Empty Base Classes, du fait que cette propriété est une conséquence de quelque chose de plus profond. Hubert Tong envisage une note. Richard Smith fait remarquer que deux objets ne peuvent occuper le même espace. Patrice Roy demande comment on traite le cas de deux parents vides. Richard Smith répond que, étant tous deux de taille zéro, ils n'ont aucun byte qui se chevauche.

GB19 : missing cv-qualification when materializing a temporary object

La terminologie de Jens Maurer semble Ok. On l'accepte telle quelle, avec une retouche de référence croisée. Ce sera proposé pour vote vendredi.

GB20 : decomposition declaration should commit to tuple interpretation early

Jens Maurer fait remarquer que la terminologie utilisée vient directement de la résolution proposée par les britanniques.

Roger Orr fait remarquer que l'un des membres de BSI est irlandais mais n'est pas content que les commentaires britanniques soient GB plutôt que UK, mais UK est l'Ukraine alors...

Ce sera proposé pour vote vendredi.

GB23 : disallow handlers taking a reference to array or function

Jens Maurer demande laquelle des options nous préférons. On prend l'option 2, mais sous forme de note non-normative.

Ce sera proposé pour vote vendredi.

GB25 : imprecise description when terminate is called

La terminologie proposée par Jens Maurer est Ok, dans la mesure où (comme le fait remarquer Hubert Tong) les spécifications dynamiques d'exceptions sont éliminées, sinon il faudra discuter d'appels à std::unexpected(). Ce sera proposé pour vote vendredi.

GB26 : 'last' active handler and multithreading

Mike Miller fait remarquer que quelqu'un a traité ceci de Pure Evil (sifflotement!). Hubert Tong mentionne que le mal ne tient pas à la terminologie proposée.

Jens Maurer explique les deux options qu'il a considéré.

Richard Smith pense qu'on a un cas de comportement indéfini dans les deux cas. Dans les deux cas, la destruction est concurrente et se fait dans un ordre indéterminé. Il suggère d'apposer une sémantique de partage à exception_ptr.

Jens Maurer suggère qu'on demande l'avis de SG1 dans ce cas.

Hubert Tong pense qu'il faut que la terminologie garantisse que la destruction se fasse au dernier point d'accès.

Richard Smith : je pense qu'on veut la sémantique d'une gestion du compteur de références qui s'apparenterait à celle d'une atomique relaxée.

John Spicer : si on veut que le comptage de références soit cohérent entre threads, il faudrait l'exprimer explicitement.

Richard Smith : avec deux threads qui lisent la même exception concurremment, l'un va détruire l'objet, donc il faut que l'autre lise l'objet avant qu'il ne soit détruit. Il nous faut donc un ordonnancement

Hubert Tong : le point clé n'est pas tant la lecture que la sortie du gestionnaire d'exceptions.

(on se questionne sur la force de la relation d'ordonnancement requise; il faut un ordonnancement total dans le programme des écritures sur le comptage de références partagé)

Richard Smith : il nous faut un Happens-Before sur les gestionnaires d'exceptions pour que ceux-ci se produisent avant la destruction des objets. Ça devient profond et on convient de laisser SG1 s'occuper des détails.

GB63, GB64 et GB65

GB63, GB64 et GB65 seront proposés pour vote vendredi.

GB67

Richard Smith : c'était sur ma liste éditoriale, mais je préférerais qu'on en discute.

L'idée est que c'est une grosse table normative, et que ça fait un peu étrange là où c'est.

On convient de la laisser aller de manière éditoriale finalement.

Introduce the term "direct member"

Ceci sert à combler un trou de définition dans la terminologie du standard. C'était dans une proposition distincte qui n'a pas survécu.

Hubert Tong fait remarquer que ce serait un Drive-By si on le faisait.

On arrête vers 17 h 30, et le plan est de se retrouver àh 30 demain matin. Je sens très fort le décalage horaire ce soir; ce fut une journée intéressante et bien remplie, mais je tire de la patte un peu. De retour à ma chambre, j'ai parlé un peu avec Za et les enfants (les deux plus jeunes, évidemment, car Marguerite et Calypso sont dans leur propre appartement maintenant et la semaine, Amandine est chez sa maman), puis je suis tombé endormi... vers 18 h 30 heure locale. Za m'a rappelé un peu plus tard pour me souhaiter bonne nuit et je me suis rendormi pour me réveiller vers 22 h heure locale,h à la maison.

J'ai constaté, en allant à la salle de bains, que la personne en charge de l'entretien a fait un bon boulot, mais a négligé de me laisser de quoi prendre ma douche (shampooing, revitalisant, gel de douche) et du papier de toilette, alors je suis allé faire un tour au lobby (où tout le monde est actif sauf moi, vous vous en doutez; il n'est pas tard même si la moitié de ma nuit est faite) où on m'a donné tout ça en plus d'un biscuit à l'avoine et aux canneberges (très bon).

J'ai travaillé un peu (un tout petit peu), puis je me suis recouché...

Jour 1 8 novembre 2016

... et c'est le réveil matin qui m'a ramené à la conscience. J'ai pris une douche, fait un peu de paperasse et de retours de courriels, puis je suis allé manger une bouchée. Saucisses, oeufs cuits durs, granola, yogourt, fruits, gruau, café (évidemment). Certains grognent que les seuls oeufs disponibles soient cuits durs. Sans grande surprise, les élections américaines se tenant aujourd'hui, c'est le sujet de conversation principal.

On recommence àh 30.

Mike Miller nous indique que RU1 est revenu de EWG qui souhaite que nous fassions le changement. Nous examinerons aussi une proposition d'Alisdair Meredith, de même qu'une proposition de Beman Dawes sur le support d'Unicode

RU1

Mike Miller dit que le texte proposé indique « If a program calls for the defaul -initialization of an object of a const-qualified type T, T shall be a class type with either a constructor that initializes all subobjects or a user-provided default constructor »

Jens Maurer dit que ce texte est incorrect et qu'il a une alternative à proposer. On l'examine.

Richard Smith pense que le cas récursif (couvrir l'initialisation des sous-objets) n'est pas bien couvert par le texte proposé. Hubert Tong pense qu'il est suffisant pour la classe de base d'avoir un constructeur maison. Richard Smith fait remarquer que la qualification const ne s'applique pas pendant la construction.

On parle d'ajouter un nouveau terme comme const-default-constructible mais il y a des cas limites (les tableaux, par exemple) et Jens Maurer dit qu'il va y réfléchir et nous revenir.


Jens Maurer nous indique qu'il y a une section Ready dans son document de propositions terminologiques.

US28

Jens Maurer a fait un tour pour éliminer le terme Principal Constructor de la terminologie. On fait diverses retouches pour clarifier la séquence de construction d'un objet tout en tenant compte des attributs, des parents, et des constructeurs de délégation.

Hubert Tong : section §12.7, on dit qu'il est illégal de toucher à un sous-objet avant que son initialisation n'ait démarré, mais c'est trop restrictif. Richard Smith fait remarquer le cas où l'initialisation est triviale, dans quel cas c'est permis. Richard Smith fait aussi remarquer que nous sommes clairs sur le point du moment où une initialisation se complète, mais pas sur le point du moment où une initialisation débute. De manière générale, la « période de construction » est mal définie (§15.17), particulièrement pour le comportement polymorphique

Hubert Tong fait remarquer que §15.2p3 et p4 le rendent inconfortable sur le plan de l'ordonnancement, considérant l'ordre dans lequel se complètent le constructeur délégant et le constructeur délégué. On retravaille le tout.

Richard Smith note que « If the non-delegating constructor for an object has completed execution » l'agace, car on ne voit pas clairement que la conclusion n'a pas été atteinte par une levée d'exception, et propose une autre formulation

Richard Smith remarque que si A délègue à B qui délègue à C, puis C complète et B lève une exception, le texte actuel détruira C deux fois. C'est un vieux bogue mais tant qu'à être là...

Jens Maurer va retravailler un peu le texte et nous revenir car il y a des liens à faire qui méritent des retouches.

Dinka Ranns propose une clarification terminologique qui m'a échappée parce que quelqu'un dans le corridor a fait du vacarme mais ça semble bien accueilli

US103

Jens Maurer a ajouté un exemple d'utilisation :

template<class T, class D = int>
   struct S { };
template<class U>
   S(U) -> S<typename U::type>;

struct A {
  using type = short;
};
S x(A());  // x is of type S<short, int>

Faisal Vali se demande si c'est un cas de Most Vexing Parse et si c'est une déclaration de fonction. Oups!

Jason Merrill fait remarquer que changer S x(A()); pour S x{A{}}; ne règle pas le problème

Jens Maurer retouche et propose :

template<class T, class D = int>
   struct S {
      T data;
   };
template<class U>
   S(U) -> S<typename U::type>;

struct A {
   using type = short;
   operator type();
};
S x{A()};  // x is of type S<short, int>

Richard Smith pense qu'on a encore un cas niche qui pourrait déduire la mauvaise chose ici, mais on découvre un truc qui n'a pas été discuté par EWG. Faisal Vali dit « C++ est vivant! ». Richard Smith est d'avis qu'une partie du dossier devrait être envoyé à EWG. Il suggère qu'on ajoute une mention empêchant d'utiliser la syntaxe ailleurs que là où ça nous semble faire du sens, du moins pour le moment, et qu'on ouvre un Core Issue pour réfléchir au problème plus profond qui vient de nous apparaître.

Mike Miller : on soumet celle-là au votre vendredi.

GB5

On cherche à nommer correctement les paramètres des templates, chose complexe car ils peuvent ne pas être nommé, et ils peuvent être auto désormais. Ce qui tenait lieu de définition antérieurement est... presque rien.

Hubert Tong fait remarquer qu'on ne peut pas utiliser le terme entity ici, car il est normé et porte un sens technique et fini dans le langage.

Richard Smith pense que la terminologie proposée ne couvre pas correctement les références. Il trace une distinction entre value (quelque chose qu'a un objet) et lvalue (expression qui mène sur un objet)

Hubert Tong souligne qu'on peut simplifier, considérant la précision (!) des définitions dans la même section, par « member of a template-parameter-list ». On rit, mais il a raison

GB6

Jens Maurer indique qu'on souhaitait avoir deux notes non-normatives, qui ont été ajoutées.

Hubert Tong souligne qu'il est possible implicitement de déborder les limites du compilateur dans du code constexpr. Faisal Vali pense qu'il s'agit du seul cas problème ici.

Patrice Roy exprime une réserve; on a une formulation ici qui sera différente de toutes les autres dans le standard. Il demande si un cas général couvrant les débordements de capacité du compilateur ne serait pas préférable. Jens Maurer pense que le traitement du comportement indéfini dans constexpr est particulier de toute manière alors on ne fera pas de miracles ici.


Mike Miller parle du plan de match pour le reste de la journée. En particulier, il faudra discuter des changements au Modules TS. Gabriel Dos Reis souhaite examiner les modifications apportées à la grammaire,

US6

Mike Miller dit que EWG nous demande de regarder cette question.

On fouille un peu. Il n'est pas clair à première vue que le texte existant ne suffise pas à la tâche. Par contre, Richard Smith fait remarquer que les cas de SFINAE clairement décrits dans le texte du standard parlent pour l'essentiel de déduction de fonctions, pas de types.

John Spicer : on sait que le problème existe, on travaille dessus, mais on ne peut pas le régler pour C++ 17

Mike Miller : rejeté pour l'instant, mais sur la table de travail pour le futur

P0195R1 : Modernizing using-declarations

Richard Smith explique la situation. Pour faciliter le recours à using avec des variadiques, on transformerait un using-declaration pour un using-declarator qui pourrait générer une expansion variadique séparée par des virgules et éviter des constructions récursives de parents.

Patrice Roy dit que les gens vont aimer pouvoir désormais faire using X::x, X::y, Y::z;.

Richard Smith se demande ce qui se passera si on a un Parameter Pack vide. Est-ce que ça effacera le nom carrément? On pense que ça devrait déclarer le nom mais le rendre mal-formé, pour que son utilisation soit illégale.

On ne le forcera pas, mais ça a été accepté par EWG à Oulu et il se pourrait que ça passe directement dans C++ 17.

Jens Maurer demande si un exemple pourrait être ajouté. On a une nouveauté car l'expansion du Parameter Pack déclare... une sélection d'entités individuelles.

Petite pause vers 10 h 15. Quelques petites salutations ici et là. Je croise Herb Sutter qui réagit très fort en voyant mon chandail de pirate, celui qu'on m'a envoyé car j'ai écrit l'un des puzzles de CppCon 2016 (les deux autres auteurs était Herb Sutter lui-même et Jason Turner), alors nous sommes un petit groupe seulement à avoir copie de ces vêtements. On a blagué un peu sur le sujet.

Ville Voutilainen a apporté une boîte de réglisses noires salées à Dinka Ranns. Semble que Dinka Ranns en ait acheté une grosse boîte à Oulu cet été, se disant qu'elle apporterait le tout au bureau et que personne n'en voudrait... mais elle est devenue « accro » à cette chose. Je me risque. C'est effectivement très salé, et très particulier. Za, si tu lis ceci : si détesterais avec passion.

D0195R2: Pack expansions in using-declarations

Richard Smith l'a retouché pendant la pause. C'est plus clair.

Richard Smith demande si on souhaite une Feature-Test Macro pour ceci. Ça semble être bien accueilli. On examine des noms possibles qui feraient référence au volet variadique ou au volet Pack, mais Patrice Roy fait remarquer que ça peut servir sans variadiques. Richard Smith suggère d'utiliser une macro faisant référence à using et à jouer avec la valeur qui y est associée. Richard Smith y repense et estime qu'on peut indiquer que le truc vraiment intéressant est le volet variadique, donc que le reste est au mieux un effet de bord, alors on y ira pour variadic_using ou un truc semblable.

Maxim Kartashev demande une précision sur le lookup des noms dans le contexte. Richard Smith fait une petite retouche à une puce.

On amène ça pour fins de vote vendredi, en vue de C++ 17 dans la mesure où le comité est d'accord.

P0329R1: Designated Initialization Wording

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0329r1.pdf

Tim Shen nous explique le projet et discute avec nous de la terminologie proposée. Ça rejoint la syntaxe C99, mais avec restrictions (il n'est pas possible d'utiliser une syntaxe de tableau en C++, et il n'est pas possible de faire .membre.membre.membre ... non plus; en retour, C++ supporte l'initialisation avec accolades).

Tin Shen explique comment sa proposition interagit avec l'ordre des initialisations, qui se fait en ordre de déclaration, et montre qu'il s'agit d'une restriction pour C++.

Quelques exemples :

union u { int a; const char* b; };
//
// ...
//
u a = { 1 };
u b = a;
u c = 1; // error
u d = { 0, "asdf" }; // error
u e = { "asdf" }; // error
u f = { .b = "asdf" };
u g = { .a = 1, .b = "asdf" }; // error
//
// ...
//
struct A { int x, y; };
struct B { int y, x; };
void f(A a, int); 
//
// #1
//
void f(B b, ...); 
//
// #2
//
void g() {
  f({.x = 1, .y = 2}, 0); // OK, calls #1
  f({.y = 2, .x = 1}, 0); // error, selects #1, initialization of a fails
                          // due to [dcl.init.list]p3
}

Patrice Roy demande si C supporte un truc comme :

struct S { int a,b,c,d; };
S s{ .a = 3, 4, .d = 5 }; // s.b==4 ou s.c==4?

Richard Smith dit que C le permet et initialiserait s.b, mais que C++ ne le supporte pas (c'est couvert par la grammaire). En C++, ils seront tous initialisés par nom (ou pas initialisés du tout), ou tous initialisés sans être nommés. De même, avec des noms, l'ordre utilisé devra respecter l'ordre de déclaration.

Hubert Tong fait remarquer que le terme initialized-element est un nouveau terme pour le standard. Il se questionne sur la pertinence du terme. Richard Smith suggère explicitly-initialized-element. Hubert Tong est d'accord.

Dinka Ranns fait remarquer que la réserve à l'effet qu'on ne peut pas avoir plus d'intialiseurs que de membres à initialiser est redondante, du fait qu'ils doivent tous êtres nommés si au moins un l'est (à moins que l'on ne permettre d'initialiser le même membre deux fois, ce qui ne semble pas être le cas).

Jens Maurer pense qu'on devrait interdire explicitement les initialiseur dupliqués dans §8.6.1.

Dinka Ranns demande comment on pourrait profiter de ce mécanisme pour une classe ayant des parents, du fait qu'il faut qu'ils doivent être tous nommés (à moins qu'elles n'aient un constructeur par défaut). On convient qu'on pourra y revenir dans le futur si le besoin se fait sentir.

Patrice Roy fait remarquer qu'avec ceci, on fait un premier pas vers le support d'agrégats anonymes retournés d'une fonction, comme :

auto creer_point(int x, int y) { return { .x = x, .y = y }; }

Richard Smith confirme. C'est pas ce qu'on fait mais ça ouvre la porte.

On fait quelques simplifications au texte par la suite.

Hubert Tong remarque un irritant grammatical dans le cas des références. Richard Smith constate une référence croisée suspecte dans §13.3.3.1 mais pense qu'on évite le pire. Hubert Tong maintient que les références ne sont pas traitées avec suffisamment de clarté.

Richard Smith demande ce que l'on fera avec le problème de §13.3.1.5 qui réfère à §13.3.1.4 pour le traitement des listes d'initialisations, alors que cette dernière de les traite pas... mais de toute manière, 13.3.5 ne sous envoie jamais à §13.3.1.5 de toute manière. On ouvre un Core Issue.

D0417R1: C++17 should refer to ISO/IEC 10646 2014 instead of 1994 (R1)

Mike Miller nous informe que ce problème a été rapporté par Beman Dawes, qui est occupé ailleurs.

Richard Smith pense qu'il y a confusion; on peut rayer le paragraphe offensant, qui ne sert pas dans le standard de toute manière. C'est la manière la plus simple de régler le problème. On l'envoie ensuite à LWG.

Hubert Tong fait remarquer que si LWG souhaite utiliser le document, alors il faudrait le conserver, mais Jens Maurer fait remarquer qu'ils se plaignent souvent que C++ n'implémente pas correctement ce genre de truc de toute manière.

Jonathan Cavesindique que Microsoft souhaite s'éloigner de MBCS, mais que c'est difficile. Ils aimeraient migrer vers UTF-8 ou UTF-16.

Mike Miller statue qu'on rayera le paragraphe offensant et qu'on informera LWG pour a suite des choses.

Core Issue 1860: What is a "direct member?"

Jens Maurer a de la terminologie pour cette résolution.

On frappe, comme c'est souvent le cas pour ce genre de truc, le cas des union anonymes : interviennent-ils pour définir ce qu'est un membre direct? On discute, mais on tend à penser qu'ils devraient etre considérés comme un membre à proprement dit. Ce qui est agaçant, comme le fait remarquer Hubert Tong, est le cas récursif. On convient que dans ce cas, l'union anonyme n'est pas un membre de la classe qui le contient, mais que les membres de cet union le sont. Malheureusement, le texte existant ne dit pas tout à fait cela, alors il y a du travail à faire. Le gros du travail ici est de trouver une écriture qui exclut correctement les membres d'une classe parent sans nuire au reste de la mécanique.

Pause pour dîner vers 12 h. Crevettes au lait de coco (panées, mais bon), saumon teriyaki, légumes sautés (très bons), riz, petits gâteaux très sucrés (je n'en ai pris qu'un, car c'est très lourd). Comme hier, mon budget étant ce qu'il est, j'ai pris un bon dîner pour ne pas avoir faim en soirée. J'ai bavardé un peu avec Jonathan Caves (qui habite dans l'État de Washington) et Mike Miller (qui habite au Massachussets) sur les rites et les lois qui permettent de voter dans ces états. Ce sont des lieux très démocrates cependant alors ça ne me donne pas un portrait réaliste de la situation américaine.

Thomas Köppe vient poser une question perverse à Richard Smith :

Est-on en face d'un design raisonnable? Et la réponse, sans surprises, est non. Brrrr.... Enfin, on reprend les travaux à 13 h.

Mike Miller : on abordera maintenant les modules.

Gabriel Dos Reis : deux documents sont à examiner.

C++ Module TS Issues List

On a plusieurs trucs à examiner.

export import M; // où M est un module

Richard Smith dit que la grammaire le permet. Ça ne fait pas de mal, mais faut voir si telle est l'intention. On supporte aussi export { import M }; avec le texte existant.

Patrice Roy dit voir des applications à ceci. Gabriel Dos Reis dit qu'exporter un module est un choix de design. On semble pencher vers le support de ce mécanisme. On pense que export M; est même plus joli que export module M; et on va suggérer à EWG de reconsidérer leur position en ce sens.

import M; // au niveau de l'interface d'un module

Le texte actuel permet à un module d'importer sa propre interface. Richard Smith propose de bannir ce cas par une clause normative. C'est pas mal l'opinion de tous les gens sur place. On travaille un peu la formulation.

Richard Smith se demande si on peut référer aux règles existantes qui banissent les cycles, mais c'est pas clair qu'on parle d'un cycle ici.

Richard Smith fait remarquer que le modules partition, qui est encore chez EWG, va nous arriver éventuellement et affecter la terminologie utilisée. Gabriel Dos Reis va nous ramener une terminologie adaptée.

export const int n = 5; // est-ce permis?

Gabriel Dos Reis fait remarquer que traditionnellement, const implique internal linkage, alors que les exportations d'un module donnent dans l'external linkage.

Richard Smith penche vers un ajustement des règles d'édition des liens dans ce cas, traitant les modules comme un cas particulier où on appliquera d'autres règles que const-implique-interne. Évidemment, on vise à réduire les risques de conflits de noms ici (deux fois le même nom, valeurs distinctes...).

Import declaration and namespace partitions

La question suivante a été posée :

module M;
export namespace N {
  struct A {};
}
namespace N {
  struct B {};
}

« §7.7.1/4 says that all members of namespace-body are exported, meaning N::A. import M;

§Says that import declaration adds the namespace partitions with external linkage from M to the current Translation Unit.

Namespace partition N from M contains both N::A and N::B. So is N::B visible and can be used in the second Translation Unit... or not? »

Richard Smith demande pourquoi on aurait besoin de namespace-partitions.

Gabriel Dos Reis dit que ce n'est pas tant une fonctionnalité qu'un élément de terminologie.

Richard Smith pense qu'on peut simplifier la règle de visibilité et éliminer complètement le concept de partition.

John Spicer demande pourquoi un namespace serait implicitement exportés. Gabriel Dos Reis dit que c'est pour simplifier la tâche des programmeuses et des programmeurs. John Spicer demande quoi faire si on souhaite ne pas exporter un namespace. Gabriel Dos Reis dit qu'il faut le placer dans un namespace anonyme. Jonathan Cavesexplique sa perspective sur le sujet, soit qu'on exporte le contenu du namespace, ou du moins la partie que l'on est en mesure d'exporter, pas le namespace en tant que tel.

Patrice Roy demande s'il y a un risque d'exporter accidentellement X si on a :

namespace N {
} 
namespace {
   inline namespace N {
      struct X{
      };
   }
}

...mais il semble que les deux N soient distincts et qu'il faille faire exprès pour se mettre dans le pétrin.


Gabriel Dos Reis demande comment faire le suivi des modifications proposées par CWG. Richard Smith dit d'aller chercher un document P-numbered et de l'amener vendredi pour fins de vote, du moins si le but est de l'amener pour cette fin. En attendant, on se revoit demain.

N4610: Working Draft, Extension to C++ for Modules

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/n4610.pdf

John Spicer mentionne que plusieurs dossiers discutés à Kona ne semblent pas avoir été adressés dans le document actuel. Des trucs comme référer à une variable static à partir d'un template, par exemple, ou pour décrire l'instanciation des templates pour ce qui est de la visibilité des noms d'un module à l'autre. Gabriel Dos Reis dit que les règles actuelles s'appliquent; Richard Smith dit l'avoir essayé dans Clang sans succès. John Spicer est d'avis que le texte doit être plus clair quant aux règles de toute manière. Richard Smith explique pourquoi les règles usuelles ont échoué dans son implémentation. John Spicer est aussi assez... expressif dans sa demande de clarification.

Gabriel Dos Reis dit que par expérience, ils y sont arrivés. John Spicer indique que si c'est facile à implémenter, c'est facile à mettre en mots.

Roger Orr demande des exemples concrets de cas à problème pour mieux cerner les difficultés. Gabriel Dos Reis dit qu'il aimerait un courriel listant quelques problèmes-clés.

Richard Smith demande si l'implémentation fonctionnelle repose sur un compilateur implémentant le Two-Phase Lookup. Jonathan Cavesdit... une phase et demie. On rit un peu.

Richard Smith dit que les membres =default sont générés tardivement en temps normal, mais que la spécification actuelle n'indique pas clairement ce qui est visible d'un template à partir du point d'instanciation. Gabriel Dos Reis rapporte la question aux pratiques en vigueur aujourd'hui. Gabriel Dos Reis indique qu'il y a une différence entre ce qui est visible dans le C++ d'aujourd'hui et celui reposant sur des modules, car on peut ne pas tout exporter d'un module. On parle de la clause §12p1.

John Spicer parle de la visibilité de déclarations, exportées ou non, et de l'explosion de cas possibles à explorer. Gabriel Dos Reis demande qu'on lui écrive les cas qui préoccupent pour qu'il n'en oublie pas. Un des cas qui surgit est :

module M;
export int f(int);
// ...
int f(int = 5); // légal traditionnellement: redéclaration ajoutant un paramètre par défaut
// lequel des f(int) est exporté?
export struct S {
   int n = f(); // valide hors de M?
   S() = default; // si on utilise S dans un autre module, sans connaître la valeur par défaut passée à f(), que se passe-t-il?
};

Gabriel Dos Reis nous quitte et reviendra demain.


Mike Miller revient sur le mot forward dans forward progress. La suppression est entendue avec SG1, mais seulement de la phrase offensante (le forward dans forward progress restera dans le reste du texte).

D0003R5: Removing Deprecated Exception Specifications from C++ 17

Alisdair Meredith revient avec une nouvelle version du texte. C'est un dossier qui traîne depuis longtemps. Il nous invite à regarder §8.3.5p8 de plus près.

Jason Merrill dit qu'il souhaite qu'il soit clair qu'une signature sans spécifications d'exceptions et une signature équivalente avec noexcept(false) sont en fait une seule et même signature.

On a de gros changements à §15.4 mais ça ne parle que de fonctions. Richard Smith fait remarquer que les cas de pointeurs de fonctions ou de références de fonctions sont absents du texte.

Patrice Roy fait remarquer que throw() est devenu aussi fort que noexcept(true), mais Alisdair Meredith rappelle que c'est une conséquence de votes récents.

Jason Merrill et Richard Smith échangent brièvement sur le sujet (connexe) du fait que depuis que noexcept fait partie du type des fonctions, une clause noexcept qui serait value-dependent ferait de la fonction une fonction value-dependent. C'est un dossier qu'il faudra traiter séparément.

Richard Smith remarque que §15.4.1 laisse entendre qu'il y a une spécification d'exception implicite si on n'écrit rien, mais que §15.4.3 semble contredire cette position. En fait, ne rien écrire implique noexcept(false), mais on pouvait autrefois redéclarer une fonction sans spécification d'exception avec une version offrant une telle spécification. Ce code sera brisé aujourd'hui...  En creusant, Richard Smith constate qu'il s'agit d'un défaut préexistant.

Alisdair Meredith souhaite quitter pour réfléchir. Richard Smith suggère qu'on remplace exception-specification à noexcept-specifier, et que cela simplifierait beaucoup de choses. Alisdair Meredith dit que ce serait un plus gros changement que ce qu'il préférait faire. Richard Smith dit que l'éditeur pourrait faire le remplacement de manière mécanique dans le texte du standard si on le trouvait.

Dinka Ranns se questionne sur les paragraphes 5 et 6 qui s'intègrent plus ou moins bien. Elle suggère de rayer le paragraphe 6 et d'en faire une note non-normative avec exemple, le tout intégré au paragraphe 5.

US 28: incorrect definition for principal constructor

Jens Maurer explique les changements les plus récents apportés à cette résolution. On retravaille car il y a des cas limites qui échappent encore à la terminologie proposée. C'est fou combien de subtilités peuvent survenir dans un langage de la complexité et de la richesse de C++. Richard Smith fait entre autres remarquer qu'un constructeur peut déléguer à un autre constructeur, mais aussi à une value-initialization ou à des constructeurs de classes de base. Il n'est pas certain qu'il soit possible de déléguer à une aggregate-initialization.

Richard Smith mentionne qu'il y a en fait toujours un constructeur, même avec une forme de value-initialization où le constructeur serait =default.

Je vous passe les détails, mais c'est un nid de subtilités que cette zone du langage qui décrit les règles applicables au début et à la fin de la vie des objets... On en parle pendant plus d'une demie-heure, pour quatre ou cinq lignes de texte subtiles.

On prend une pause un peu passé 15 h 15. C'est bête car on est dans le bain et que c'est difficile de s'arrêter en pleine réflexion, mais certains n'en peuvent plus et ont besoin d'une pause. Il se trame plusieurs trucs politiques amusants, et on a plusieurs visites incluant Herb Sutter et Ville Voutilainen. Je crois comprendre entre autres que les modules seront discutés à Kona en 2017 plutôt que cette semaine, pour donner à la fois aux divers implémenteurs l'occasion d'accumuler plus d'expérience et à l'auteur de raffiner sa proposition en l'enrichissant de manière à mieux guider les implémenteurs.

Jens Maurer a une mise à jour pour US28. C'est un monstre de phrase avec six virgules et beaucoup de cas particuliers, mais ça semble correct. On est pas mal tous d'accord pour l'accepter.

On le votera vendredi.


Mike Miller dit que EWG souhaite que contrairement aux autres changements qui visent pour la plupart directement C++ 17, celui-ci soit traité comme un DR. Jens Maurer pense qu'on a plusieurs DR dans le lot. Mike Miller dit que l'important est qu'ils soient présentés séparément pour des raisons procédurales. En effet, les DR s'appliquent à C++ 14, et les autres s'appliquent à C++ 17

RU1: CWG 253: Why must empty or fully-initialized const objects be initialized?

Jens Maurer clarifie ce à quoi s'applique cette résolution. Le nouveau texte introduit le concept de const-constructible. C'est étonamment subtil à définir encore une fois.

Patrice Roy suggère de renommer ce nouveau concept, puisqu'il envoie un drôle de message (on peut, après tout, créer des trucs const qui ne soient pas const-constructible en leur passant des paramètres). C'est moche, car les noms courts sont plus agréables, mais je crains une confusion si le nom porte mal sont concept.

On le votera vendredi.


On se demande pourquoi certains des dossiers qu'on attendait d'EWG ne nous sont pas revenus. À voir...

D0057R7: Wording for Coroutines

Gor Nishanov montre les changements apportés suite aux discussions menées hier. Il y en a plusieurs.

Richard Smith fait remarquer qu'il manque un cas de fonction membre dans §5.3.8p3.3. Gor Nishanov fait remarquer que la structure imposée à la séquence de puces explique que ce cas ait été traité précédemment.

Un problème possible survient lors de la spécialisation de l'opérateur co_await par des bibliothèques tierces sur un même type. La question soulevée tient au moment où ceci est considéré. Richard Smith trace un parallèle aec l'opérateur -> pour lequel il y a une séquence d'appels possibles. Jens Maurer mentionne aussi l'opérateur « . » qui poind à l'horizon. Gor Nishanov demande s'il est préférable de placer le texte normatif pour co_await dans la clause 13, qui porte sur la surcharge des opérateurs.

Jason Merrill mentionne qu'il y a deux trucs qui peuvent devenir awaitable. Peut-on les joindre? Un opérateur co_await binaire, en quelque sorte. Gor Nishanov mentionne l'existence de deux catégories de programmeuses et de programmeurs, qui pourraient parfois souhaiter un portrait détaillé et dans d'autres cas limiter leur attention à un sous-ensemble seulement.

Jens Maurer pense qu'il serait sage de réduire le couplage dans cette proposition entre CWG et LWG. Selon lui, on pourrait en placer plus du côté de LWG. Il trace un lien avec operator new et operator delete, au sens où le mécanisme de base fonctionne mais le volet proposé aux usagers est tel qu'il est possible de l'adapter aux besoins plus spécialisés. Richard Smith ouvre la porte à représenter co_await, co_yield et co_return sous forme d'opérateurs spécialisables plutôt que sous forme de fonctions. Jens Maurer demande comment on pourrait traiter le co_return d'une coroutine void, mais Richard Smith pense qu'un co_return sans paramètre suffirait.

Jason Merrill mentionne que les multiméthodes seront un problème auquel il faudra réfléchir ici

Mike Miller pense qu'on devrait relayer ceci à EWG. Jason Merrill pense que LEWG serait une meilleure tribune. Richard Smith pense que pour un TS, on peut continuer avec ce qu'on a. On poursuit donc avec les changements sur la table.

Dinka Ranns parle de 5.3.8p5.1. Gor Nishanov mentionne que le changement provient d'une demande de Hubert Tong. On échange sur la formule la plus claire. Il semble qu'on suggère un retour à la forme précédente, en partie. Gor Nishanov a un moral remarquable dans les circonstances.

La plupart des changements demandés (gestion des cas où on frappe la fin d'une fonction sans retourner; gestion des paramètres par référence; contexte lors d'une reprise d'exécution; etc.) sont bien faits. On fait des retouches mineures ici et là.

La bonne nouvelle : en fin de compte, il manque un détail mineur (jonction des méthodes et des fonctions globales), et on pourra avoir un WD en vue d'un TS. Chic!


Mike Miller suggère qu'on catégorise les DR et les non-DR.

DR : US28, GB5, GB6, GB23, GB25, GB63, GB64, RU1

Non-DR : US103, GB19, GB20, GB65

Thomas Köppe arrive pour qu'on discute de sa proposition d'élision de virgules dans les macros

P0306R1: Comma omission and comma deletion

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0306r1.html

Thomas Köppe explique le problème. Les macros variadiques acceptent les virgules redondantes car elles ne permettent pas de détecter quand arrêter d'en ajouter. Il propose un mécanisme « magique » nommé __VA_OPT__ qui peut être vide ou non, ce qui permet entre autres d'appeler une macro variadique sans paramètres.

Hubert Tong indique que le Token Pasting interagit avec __VAR_OPT__ et il se peut que le contenu remplacé doive reposer sur un tout nouveau mécanisme.

Thomas Köppe dit que des conseils l'aideraient pour améliorer la terminologie. Il n'y a pas de presse, car on vise C++ 20 avec ceci.

Jens Maurer blague qu'on a désespérément besoin d'un autre langage Turing Complete à l'intérieur de C++.

Hubert Tong décrit les options qu'il envisage :

Thomas Köppe se demande si __VA_OPT__(__VA_ARG__) fonctionnerait. Richard Smith pense que si. Peut-être avec un remplacement par nom de macro. En jasant, les modèles semble pouvoir se joindre en un modèle commun.

Thomas Köppe demande si on pense que c'est une mauvaise idée. On blague en disant qu'on n'a pas le droit d'avoir une opinion esthétique. John Spicer lance que c'est le meilleur raffinement au préprocesseur qu'on ait vu cette semaine.


Mike Miller nous amène vers FI20, qu'EWG nous a envoyé, qui dit ceci :

auto [a, b, c](expr);

... n'est pas valide présentement, mais devrait probablement l'être car on permet cela :

auto [a, b, c]{ expr };

Jens Maurer pense avoir une terminologie pour ceci.

Richard Smith pense que FI21 devrait aussi être dans la talle d'EWG. Mike Miller dit avoir reçu un courriel d'EWG pour ceci. C'est un bête oubli, car on permet cet usage d'accolades partout dans les cas connexes. Mike Miller suggère qu'on apporte le vote vendredi; Jens Maurer a déjà écrit un bout de texte juste pour ça.

À propos de US93 et GB27, Ville Voutilainen nous renvoie la balle alors on l'examinera demain matin.

Hubert Tong demande si on attend encore après LEWG pour savoir si on a std::byte pour travailler. Mike Miller dit qu'on l'a approché à ce sujet cet après-midi mais qu'il ne se souvient plus des détails. Il va aller aux nouvelles.

US 94, GB 13: class template deduction in explicit type conversion using a braced-init-list

Jens Maurer a une terminologie pour ceci. Ça vise à unifier l'initialisation avec parenthèses et celle avec accolades dans un cas de programmation générique avec conversion.

Le texte semble une simple extension du texte existant, mais Richard Smith fait remarquer que les termes grammaticaux utilisés sont tels que dans le contexte du standard, le paragraphe ajusté (§5.3.2p2) ne sera jamais atteint car le paragraphe précédent (§5.3.2p1) sera toujours celui qui entre en jeu. Il faudra insérer §5.3.2p2 au milieu de §5.3.2p1 et séparer ce dernier en deux pour que la règle souhaitée s'applique.

On travaille un peu le dossier. Richard Smith suggère qu'on examine la règle de §7.1.7.5 qui couvre les templates et qui est plus simple. Jens Maurer pense que c'est une bonne idée.

On ferme vers 17 h 30. J'essaie de rejoindre ma belle Za avant qu'elle n'aille se coucher. Ce soir, de notre côté, il y a rencontre pour l'évolution des outils numériques avec Lawrence Crowl; même si ce n'est pas ma force, je vais essayer d'y aller (entre autres parce que je ne veux pas que la salle soit vide dû aux élections). Les élections sont d'ailleurs très serrées en ce moment, et on ne sait pas de quel côté la Floride va pencher encore.

Après une petite quasi-sieste (merci à Za pour m'avoir écrit), je descends à la rencontre sur les outils numériques. L'élection américaine est extrêmement serrée...

On commence vers 20 h 7. Hubert Tong demande si on peut apporter les considérations qui touchent CWG. Lawrence Crowl dit ne pas en avoir entendu parler.

Les points de discussion ce soir sont :

Lawrence Crowl souhaite des propositions et un début de terminologie montrant la fonctionnalité attendue, On ne vise pas la perfection. L'idée est d'assembler un Working Draft.

Patrice Roy : c'est gênant que les gens passent par Python ou Erlang pour faire leurs calculs sur des entiers de taille arbitraire, puis reviennent à C++ pour le reste. Ça me semble urgent.

Lawrence Crowl : d'accord.

(plusieurs échanges s'ensuivent, mais c'est technique)

David Sankel : pour les gens de la finance, il importe que les choix faits soient efficaces en espace et en temps.

Les débordements sont impossibles dans un programme bien analysé. Indéfinis avec des entiers signés et des nombres à virgule fixe non-saturés. On peut avorter, lever une exception, faire un traitement « spécial » à la IEEE, saturé (nombres à virgule fixe), faire un modulo..

Discussion sur des types comme cardinal<int>, integral<int>, nonnegative<int> et negatable<int>

(ça dérape dans la technique pour un bout)

Walter E. Brown fait remarquer qu'il y a plusieurs manières d'obtenir les diverses interfaces mentionnées dans les discussions, et suggère que l'on soit ouvert à ces variations d'interfaces

On discute des variations de « performance » en fonction des intervalles de valeurs supportés

David Sankel pense que Boost serait une meilleure plateforme de test qu'un TS.

Patrice Roy dit qu'un TS lui sied, mais qu'il veut (a) un type short float, (b) un type entier dans limites, (c) un type de nombres à virgule fixe, en plus de (d) expérimenter avec les raffinements à <random>, et (e) veut savoir quand on pourra expérimenter avec ces nouveaux outlis pour les intégrer dans C++ 20.

 José Daniel Garcia rappelle que plusieurs entrerprise refusent d'utiliser Boost.

Walter E. Brown : si le groupe converge vers un WD, il faudrait informer LEWG dès cette semaine de l'avènement d'un TS et d'un horizon de production, et d'appeler des propositions.

On demande si la proposition doit être centrée sur des types. Et si des extensions à <cmath> peuvent être une bonne avenue.

Walter E. Brown : à l'époque, LWG/LEWG a indiqué « selon nous, SG6 'possède' les clauses numériques ».

Nathan Myers : devrions-nous spécialiser complex? Lawrence Crowl : par pour le moment

Jens Maurer : et les calculs SIMD? Lawrence Crowl : je ne pense pas.

Walter E. Brown prend le plancher pour deux présentations :

Patrice Roy demande si on veut un, deux ou trois TS

Lawrence Crowl indique que numeric_limits<T> permet de produire un NaN mais pas de le tester (pour ça, il faut <cmath>)

Hubert Tong dit craindre qu'on cherche à reconstruire le langage à partir de zéro. Walter E. Brown prend position pour le bris de compatibilité.

J'ai quitté peu de temps avant la fin de la rencontre (il était 23 h environ) pour appeler mon amoureuse Za et écouter la fin des élections américaines, sur lesquelles je me suis endormi...

Jour 2 9 novembre 2016

... pour me faire réveiller par la diffusion du discours de François Hollande félicitant Donald Trump avec le maniement du verbe très Français qu'on lui connaît. Bon, faudra voir quelles seront les conséquences de cette élection hors-normes sur l'ambiance de travail aujourd'hui; à mon avis, ce sera très professionnel, comme ce le fut lors du vote du Brexit pendant nos travaux à Oulu.

J'ai fait le tour des courriels, pris ma douche, me suis un peu rasé (avec les rasoirs jetables que j'ai traînés avec moi), puis je suis allé prendre un bon déjeuner (même patron que lundi, soit oeufs, bacon, pommes de terres rissolées aux herbes, fruits, viennoiseries, café). Je suis allé voir Walter E. Brown pour valider que la soirée s'est bien terminée (semble que si); j'ai aussi bavardé avec Howard E. Hinnant à qui j'ai appris qu'on ne doit pas donner de raisins aux chiens (merci à Za d'avoir fait mon éducation en ce sens), blagué avec Matt Calabrese à propos de Regular void, un dossier subtil qu'il pilote ces temps-ci (il me dit qu'il n'a pas de proposition en ce sens cette semaine, mais qu'il compte en faire une pour Kona en février), puis je suis allé m'installer pour manger et travailler. Je n'étais pas le premier dans la salle àh 35 du matin.

Plusieurs blaguent sur la fermeture des frontières aux migrants américains, mais tel que prévu, ce sont des blagues très douces et on se dirige vers une journée de travail entre professionnels. En allant à la salle de bains, je me fais interpeller par Bryce Adelstein Lelbach qui veut (à la blague) revenir avec moi à Montréal. Je lui ai dit qu'il faudrait qu'il se mette au hockey.

 Zut! Je viens de m'apercevoir qu'aujourd'hui est le « jour des t-shirts inappropriés ». À chaque rencontre, le mercredi (je pensais que c'était le jeudi!), les gens portent des t-shirts de compétiteurs (p. ex. : Jason Merrill, qui est en charge du compilateur à code ouvert g++, porte un chandail de Visual Studio, un produit de Microsoft; Richard Smith de Google porte un chandail de Facebook). Faudrait que je mette la main sur un chandail de C# ou de Java pour la rencontre de février...

Mike Miller demande à Jens Maurer ce qu'on doit indiquer à SG1 pour GB26. Jens Maurer dit que la question de fond est de savoir s'il est du domaine du comportement indéfini si deux threads gèrent la même exception concurremment sans synchronisation.

Core Issue 1860: What is a "direct member?"

Richard Smith pense qu'on n'est pas encore tout à fait sur la bonne terminologie. Pour les union anonymes, se basant sur le traitement réalisé par les divers compilateur, sil se dit d'avis que l'union anonyme est un membre direct, pas ses membres. C'est une drôle de bestiole : l'union anonyme est un type, mais l'objet qui en est instancié est ce dont on veut parler, or ce truc n'a pas de nom.

Thomas Köppe suggère qu'on lui donne un nom pour fins d'exposition. Richard Smith propose une tournure de phrase. En pratique, un truc comme :

struct X {
   union {
      int n;
      float f;
   };
};

... donne deux membres à X, soit le type qui est l'union anonyme et l'objet qui est de ce type. Mike Miller suggère qu'on appelle ces trucs des anonymous union objects. On achète le concept : ça nous permettra de nommer la bête par la suite.

Faisal Vali s'interroge à savoir pourquoi on utilise anonymous union object plutôt que variant. L'idée est qu'on vise à régler un cas pressant pour C++ 17. On verra plus tard pour des réflexions plus en profondeur.

On en arrive à quelque chose de pas mal. Ce sera prêt pour vote lors de Kona 2017.

RU 1: CWG 253: Why must empty or fully-initialized const objects be initialized?

On retravaille un peu. Jason Merrill pense qu'on peut simplifier encore, mais on hésite à cause des union anonymes. On l'enverra comme ça.

US 93: argument evaluation order when calling an operator function

C'est un ajout d'exemple pour clarifier ce qui se passe quand on utilise un opérateur en notation infixe ou sous forme d'un appel de fonction :

struct S {
  S(int);
};
int operator<<(S, int);
int i;
int x = S(i=1) << (i=2);
int j;
int y = operator<<(S(j=1), j=2);

Ici, suite aux initialisations, la valeur de i est 2, mais il n'est pas spécifié si j vaut 1 ou 2.

US 94, GB 13, FI 21: class template deduction in explicit type conversion using a braced-init-list

C'est un ajout grammatical qu'il faut valider. On est d'avis que le changement est évident, et n'altère pas les possibilités d'écriture de code, mais il y a confusion entre notre vision et celle d'EWG. Jason Merrill s'offre pour aller parler à Ville Voutilainen à ce sujet, mais Mike Miller va prendre cette prise de contact en charge.

Richard Smith est à l'aise avec la terminologie proposée.

Je prends le Wiki à partir d'ici, car Jens Maurer doit aller présenter quelque chose dans une autre pièce, ce qui explique le changement de format.

FI 20: decomposition declarations with parentheses

Core Issue XXXX: ... (« Issue 40 B.C. », ref-list-overload-resolution.html)

D0270R2: Removing C dependencies from signal handler wording (taken from the SG1 Wiki)

Petite pause vers 10 h 30 environ. J'apprends de Thomas Köppe que la proposition de Louis Dionne à l'effet de typer un peu plus les λ génériques a été acceptée en principe pour C++ 20 par EWG, ce qui constitue une excellente nouvelle.

Quelqu'un fait remarquer que CWG ne reçoit pas assez de propositions de type « Poisson d'avril ». John Spicer dit qu'il comprend pourquoi EWG est le groupe le plus « gâté » de ce côté : après tout, c'est plus difficile pour eux de distinguer le vrai du surréaliste (étant donné qu'ils reçoivent les propositions de trucs complètement nouveaux).

D0270R2: Removing C dependencies from signal handler wording (taken from the SG1 Wiki), suite

Modules issues list

Mike Miller demande à Gabriel Dos Reis pourquoi il nous faut une proposition pour US21. Gabriel Dos Reis dit qu'il faut que ça fonctionne, c'est tout.

Petite pause pour dîner. Il est 12 h. Des canelloni farcis au fromage, de la salade, des croutons, du parmesan, du poulet dans une sauce aux artichauts, et des desserts extrêmement sucrés.

On a reçu des nouvelles de Bjarne Stroustrup, absent cette semaine, qui dit ne pas être en mesure de venir (c'est sa troisième rencontre manquée à vie, et il est là depuis les tout débuts) mais ne pas avoir perdu intérêt envers le langage. Il se dit par contre triste que les petites avancées aient pris le pas récemment sur les progrès plus ambitieux, et nous exhorte à réfléchir à un moratoire sur les petites choses pour nous concentrer sur les trucs les plus importants. Considérant les efforts investis dans les modules et les coroutines cette semaine, j'espère qu'il apprécierait.

Je reprends le Wiki, Jens Maurer devant encore s'absenter. On redémarre vers 13 h 7.

P0266R1: Lifting Restrictions on requires-Expressions

P0433R0: Toward a resolution of US7 and US14: Integrating template deduction for class templates into the standard library

Exception specifications

US 72: unify std::byte and unsigned char

On discute de l'état du texte sur std::byte. LEWG discute du nom, puis ça tombe dans la « talle » de Library.

Core Issue 2191: Incorrect result for noexcept(typeid(v))

Semble que dans le cas très particulier de typeid, on peut examiner un nullptr déréférencé et on ne tombe pas, mais seulement là, dans le comportement indéfini. C'est un cas niche d'entre les cas niches.

Jens Maurer va retravailler le texte (en soi très court).

LWG active issue 2770

Mike Miller nous dit que nous avons reçu ceci :

« Regarding lwg active issue 2770 [1] (tuple_size<const T> specialization is not SFINAE compatible and breaks decomposition declarations): In addition to the proposed library-side resolution, we believe that it would also be best if, with respect to structured bindings, the cv-qualifiers of what would have been the argument to tuple_size are instead first stripped off, such that it is never actually implicitly instantiated with a cv-qualified type in this context.

In other words, with:

struct X { int a, b; };
const auto [x, y] = X();

The language would only instantiate tuple_size<X> as opposed to tuple_size<X const>. Note that this removal of qualifiers should only be done with respect to tuple_size, with the uses of tuple_element, etc. remaining unchanged. »

Richard Smith n'enlèverait pas les const ici. On convient de rejeter la proposition.

P0076R3: Vector and Wavefront Policies

Richard Smith : §7.6, la définition du terme « évaluation » déroge un peu des usages, mais c'est très local.

Le document est plus de type Library que de type Core. Je ne sais pas ce qu'on va en faire, si on en fait quelque chose.

Brève pause café vers 15 h 20. Je cogne un peu des clous cet après-midi. Il y a des gâteaux et des fruits; je prends un peu de café, un petit morceau de gâteau (c'est fou à quel point ils sont sucrés ici) et une pomme avant de retourner travailler.

Comme nous nous installions pour travailler, nous avons été informés que des propositions quant à la génération automatique des opérateurs de comparaison seraient débattues chez EWG, alors nous sommes partis en groupe participer aux débats. Je n'ai pas pris de notes, alors sommairement :

Lawrence Crowl a présenté une approche pour formaliser par des fonctions les concepts d'ordonnancement partiel et total.

Walter E. Brown a proposé une approche pour remplacer les opérateurs relationnels manquants par un équivalent logique lorsque ceux-ci ne sont pas définis.

Aucune des deux démarches ne manque d'intérêt, mais aucune n'a emporté l'assentiment de l'assemblée. Quelques enjeux :

On n'a pas fini de travailler là-dessus, manifestement.

Je m'endormais en fin de journée, alors je suis remonté à ma chambre, j'ai parlé brièvement avec Za, Vayda, Ludo et Marguerite (qui semblait avoir eu une grosse journée). J'ai ensuite fait une mini sieste, dont m'a sorti mon réveil. Avant d'aller à ma rencontre de soirée, j'ai eu le bonheur de voir les plus récents dessins de Vayda : un sérieux Wow! C'est fou ce que nos enfants ont du talent!

La séance de soirée vise la question des entrées/ sorties dans un contexte d'interface personne machine graphique. Brett Searles, auteur de la proposition, est parmi nous. Herb Sutter le présente.

Brett Searles souhaite parler de son approche basée sur la gestion d'événements. Il s'est inspiré de C# et de JavaScript d'abord, puis a examiné Boost.Signals et Qt. Il propose une approche reposant sur un gestionnaire d'événements générique procédant par rappels.

Brett Searles parle des pratiques en vigueur présentement. Il propose une architecture reposant sur un trio de classes : event_base (classe abstraite), event_args_base et event_base_container

Jens Maurer fait remarquer quelques trucs perfectibles dans l'interface proposée (des objets qui portent le nom de mots clés, des pointeurs qui pourraient avantageusement être des références). Il devient vite apparent qu'il y a encore un peu de travail à faire avec ce design. Loïc Yvonnet fait pour sa part remarquer qu'étant donné l'état dans lequel se trouve le code proposé, il serait préférable de se retirer pour le moment. Une proposition comme celle-ci devrait selon lui être basée sur des cas d'utilisation clairs.

Quelqu'un fait remarquer que le recours aux fonctions virtuelles n'est peut-être pas la meilleure approche ici. Un autre propose de jeter un coup d'oeil à Boost.Asio à titre d'inspiration. Je ne prends pas tout en note, mais les gens sur place sont gentils et essaient d'offrir un maximum de conseils et d'orientation à l'auteur de la proposition.

Herb Sutter suggère deux votes : un pour connaître l'intérêt général pour la gestion des événements, et un autre pour valider l'intérêt pour l'approche poursuivie par l'auteur. Patrice Roy fait remarquer qu'il est trop tôt pour des détails; il nous faudrait d'abord un document de design, décrivant un plan de match et indiquant les responsabilités de la bibliothèque standard et celles du code client. Tony Van Eerd donne des conseils de style de programmation pour moderniser l'approche proposée.

On prend des votes. L'une des orientations proposée par Jens Maurer et par moi-même est que, si nous devons développer un nouveau système d'événements, il serait sage qu'il converge vers celui du Networking TS.

On termine vers 21 h 30 heure locale. Je suis claqué. Petit bonne nuit à mon amoureuse, puis dodo.

Jour 3 10 novembre 2016

Debout àh  heure locale, petite jasette avec les enfants et avec Za, douche, et on se met au travail. La session d'hiver se profile à l'horizon, et les réunions commencent à s'inscrire à l'horaire, or dans mon cas, moi qui se trouve à donner des cours intensifs en début d'hiver, il n'y a que très peu de cases horaires disponibles alors c'est complexe. Aussi, je vais manquer une réunion de la commission des études cet après-midi, étant un peu loin pour y assister. Comme on me l'a déjà fait savoir, j'ai un horaire... acrobatique.

En me servant un déjeuner (saucisses, fruits, muffins anglais au blé entier, omelette légumes et parmesan), j'ai croisé Beman Dawes, avec qui j'ai blagué que le décalage horaire commençait à faire moins mal... maintenant que le retour à la maison approche. On a convenu de la folie un peu « addictive » de ce genre de rencontre où le sur-stimuli intellectuel fait que notre cerveau fonctionne toujours à pleine capacité, et qu'on en oublie presque le fait un peu absurde qu'on paie pour travailler.

Contre-emploi en quelque sorte : pendant que les gens mangent leur déjeuner et se préparent pour la journée de travail somme toute costaude qui s'annonce, je corrige des travaux en C# pour mes ami(e)s de première session au SIM (Sciences mathématiques et informatique), que je salue si elles / ils lisent ceci.

Mike Miller : on a quelques dossiers résiduels de Oulu à traiter. Jens Maurer a préparé une proposition pour l'un des trois qui n'était pas banal.

D0507R0: Core Issue 1343: Sequencing of non-class initialization

Jens Maurer explique l'intention de la proposition. On fait quelques clarifications mineures, mais on avait déjà vu celui-là alors le niveau de maturité est déjà très bon.

Richard Smith demande quelques clarifications, mais le fait que l'on parle de constant-expressions, réalisées avant l'exécution du programme, fait que les effets intermédiaires ne sont pas observables. Il suggère qu'on ajoute quelques cas. On pense ajouter un nouveau terme grammatical pour clarifier le discours. Quelques retouches d'accord en nombre sont faites pour que l'intention soit limpide.

On le passera pour fins de vote vendredi. On aurait pu attendre à Kona, mais vu qu'il s'agit d'un correctif sur le standard existant, on préfère le faire passer plus rapidement (surtout qu'on l'avait déjà travaillé par le passé)

D0270: Questions

Mike Miller mentionne la nouvelle lecture faite de la proposition de Hans Boehm sur les fonctions signal-safe ont fait naître des questions :

« The comments are not entirely clear to me. It would be great to talk to a volunteer who was in on the discussion.

I agree that "signal safe function" isn't quite right. We're really talking about dynamically invoked operations. I can try to restate, but it would probably be more effective if a CWG expert participated.

There's currently a fundamental issue that the place at which static initialization may occur is so weakly defined that most programs using it are probably broken. I attempt to somewhat fix this in another paper, D0250 that you should see shortly. "Somewhat" here means that we make it implementation-defined when initialization takes place, rather than letting it happen at any point. If it could indeed happen anytime before the first ODR-use, it could commonly happen inside a critical section holding a lock needed by the initialization. I've arrived at the conclusion that real code works because programmers actually do at least somewhat know when initialization might take place, and it doesn't randomly happen in the middle of a critical section.

I suspect the real fix here would be be to require initializations to happen before main in the main thread. But that seems to restrictive for current implementations. In any case, I think this should be left for D0250. »

Ça semble raisonnable. On reçoit entre-temps D0250.

D0250R3: Wording improvements for initialization and thread ids (CWG 2046, 1784)

C'est une réflexion quand même subtile sur le début et la fin de la vie des objets, et les risques d'initialisation ou de destruction concurrente. Patrice Roy confirme auprès de Jens Maurer que le standard comprend des passages empêchant l'implémentation de lancer des threads autres que main() pour procéder à de l'initialisation concurrente des globales (la proposition en dépend mais n'en parle pas); Jens Maurer confirme que si un programme ne lance pas lui-même de threads, alors l'implémentation ne peut en lancer d'elle-même.

John Spicer suggère qu'on demande un clarification des règles, en particulier pour le cas où l'initialisation doit précéder le premier ODR-use de l'objet. Patrice Roy indique que c'est une bonne idée, car les gens qui font des systèmes en temps réel voudront connaître les enjeux quand aux délais semi-prévisibles introduits par l'initialisation plus paresseuse que ceci permettra.

Hubert Tong dit que la terminologie impose une initialisation-avant-main() si elle se fait dans le même thread que main(), mais que c'est plus flou dans un thread tiers.

Jason Merrill pense que c'est implementaton-defined si l'initialisation est sequenced-before main().

Hubert Tong voit un problème du fait que first-ODR-use est sous-spécifié pour le moment.

Richard Smith estime que c'est un bogue terminologique préexistant. Selon lui, il faudrait remplacer first-ODR-use par every ODR-use, surtout dans un monde concurrent et surtout s'il y a des cycles dans l'interconnexion des modules objets à l'édition des liens.

Jens Maurer fait remarquer que ces irritants, bien réels, ne concernent pas la proposition de Hans Boehm. Hubert Tong est moins confortable; le modèle mental mis de l'avant, s'il est bien documenté par les implémentations, a une certaine valeur. Faut être prudents, cas un programme qui lance des threads peut voir l'implémentation déplacer l'initialisation des globales sur ces autres threads dans la mesure où les objets sont tous initialisés avant premier ODR-use. Selon Hubert Tong, les accès concurrents sur les objets ainsi initialisés sont un peu sur les épaules des usagers.

Richard Smith pense que si nous corrigeons la terminologie sur first-ODR-use pour que ça ne s'applique qu'aux moments opportuns, on pourrait faire disparaître le problème.

Hubert Tong va collaborer avec Hans Boehm pour cette partie du problème. Il se peut que Richard Smith s'en mêle aussi.

Richard Smith indique que §3.6.3p4 est incorrect. En particulier, les variables non-locales et inline avec durée thread-local ne sont pas traitées correctement. Il y a du travail à faire là. Aussi, §3.6.3p5 est incorrect si on compare avec §3.6.3p2 pour l'ordre d'initialisation (il y a des cas manquants); des liens avec §3.6.3p1 sont à envisager. Ce qu'il faut comprendre est que l'ordre d'initialisation des thread-local est sous-spécifié. Entre autres, il existe une stratégie d'initialisation pour les thread-locals où on alloue la mémoire sans l'initialiser, attendant que la mémoire soit touchée pour protéger et laisser le page-mapper s'en charger, mais la terminologie existante empêche ce type de manoeuvre.

Hans Boehm sera informé des retouches à faire.

À retenir : il y a quelques cas possibles d'initialisation paresseuse en C++, et faudra avertir les usagers de type « basse latence » ou « temps réel »

US 94, GB 13, FI 21: class template deduction in explicit type conversion using a braced-init-list

On relit pour approuver les dernières modifications. Ça semble bien. Go pour vendredi.

GB 26: 'last' active handler and multithreading

Patrice Roy maintient que cette horreur est le mal incarné. Jens Maurer décrit les options. Si on passe pas un pointeur avec sémantique de partage, il y a crainte de perte de « performance »; Patrice Roy laisse entendre que rendu là, la « performance » est le dernier de nos soucis.

Jens Maurer fait remarquer que exception_ptr peut toujours être copié en profondeur; le standard n'impose pas de le partage avec une forme de comptabilité de références.

Richard Smith demande une précision sur « consistent with happens-before relation ». Jens Maurer dit que c'est ce qui définit l'idée d'un ordre total sur l'exécution du programme. Richard Smith mentionne qu'il est possible que les gestionnaires n'aient pas une telle relation. Jens Maurer mentionne qu'on peut en prendre un au hasard tant que le programme a un ordre total. Jason Merrill fait remarquer que la synchronisation clé est sur la destruction de l'objet représentant l'exception. Richard Smith favorise une terminologie plus stricte, disant que tous les accès sur cet objet happens-before sa destruction.

Pause brève pour prendre du café, puis on redémarre. Journée occupée...

GB 26: 'last' active handler and multithreading

Jens Maurer revient avec une nouvelle terminologie. L'écriture permet de placer la synchronisation requise pour la gestion de la concurence sur la mort de l'objet représentant l'exception dans exception_ptr.

Richard Smith mentionne un inconfort avec happens-before dans cette situation. Jens Maurer suggère strongly-happens-before,, mais il faudra attendre que la proposition de Hans Boehm en ce sens soit acceptée.

Ça passera au vote vendredi en tant que DR.

GB 27: multiple activations of the same exception object

Patrice Roy demande une précision sur uncaught_exceptions(), représentant le nombre d'exceptions en vol dans le thread courant, suivant les échanges sur GB26, qui laisse entendre la possibilité de traiter une même exception concurremment dans deux threads ou plus. Hubert Tong note que cette fonction tend à intervenir dans la destruction des objets, pour savoir si plus d'une exception est en vol à ce moment, et qu'il s'agit d'une propriété monoprogrammée de manière inhérente.

Mike Miller demande si une note serait sage dans ce cas. Jens Maurer pense qu'on est proche d'un NAD ici, mais que l'ajout d'une référence croisée peut suffire. Mike Miller fait remarquer qu'il semble y avoir une erreur de catégorie ici (confondre exception et exception object). Richard Smith confirme.

On le passera au vote vendredi, en tant que DR.


Mike Miller demande à John Spicer des précisions quant aux préoccupations soulevées face au Modules TS. John Spicer dit avec mis Jonathan Caves en contact avec Gabriel Dos Reis pour clarifier ces trucs un peu obscurs. John Spicer apprécierait que ces irritant soient réglés avant que l'on vote que le Modules TS. Richard Smith mentionne un besoin de clarifier les règles d'ADL en lien avec les symboles importés. Mike Miller en informera Herb Sutter.


Mike Miller parle ensuite des échanges avec Walter E. Brown pour lesquels Hubert Tong a rédigé une note. L'ajustement proposé indique :

[ Note: If the requires-expression does not appear within the declaration of a templated entity, then the program is plain ill-formed. –end note ]

On sourit à l'apparition de plain ill-formed dans la terminologie, mais il y a de la résistance et on l'élimine. Richard Smith remarque un problème pour ce qui est de la formulation de cette note dans son contexte. On réajuste et on arrive à ceci :

[ Note: If a requires-expression contains invalid types or expressions in its requirements, and it does not appear within the declaration of a templated entity, then the program is ill-formed. –end note ]

On adoptera (ou non) le tout quand on aura vu le texte de Walter E. Brown. On ne s'attend pas à beaucoup de problèmes.


Mike Miller demande si on peut passer à une dernière revue du Issues List pour le Modules TS. On procède.

Resolved Module TS (N4610) Issues

Patrice Roy souligne que le document semble conforne aux dernières demandes qui ont été formulées. Il reste des retouches mineures (date du document, genre).


Hubert Tong indique que les opérations arithmétiques autres que des conversions et générant un infini ne devraient pas être valider dans une constant-expression. De même, de l'infini qui donne un non-infini serait du narrowing, pas du comportement indéfini (ça surprend Thomas Köppe, mais Richard Smith indique que c'est selon l'implémentation et que ça peut survenir dans un cas de double vers float par exemple).

Roger Orr fait remarquer que cela signifie qu'une constant-expression peut contenir une infinité, mais qu'on ne peut y ajouter zéro.

Richard Smith recommande qu'on pousse sur SG6 pour clarifier ces questions. Idéalement, ils examineraient ce que C fait.

Jens Maurer note que C++ ne garantit pas le soutien de IEEE 754. On peut difficilement clarifier le comportement face à l'infinité sans définir l'infinité.

On veut expliciter que certaines expressions manipulant l'infinité dégénèrent en comportement indéfini.

Hubert Tong mentionne que l'inspiration est dands <float.h>. Aussi, <fenv.h> est inutile en C++, ayant une dépendance sur un autre en-tête qui n'y existe pas. Thomas Köppe dit que c'est mentionné dans §26.4.1.


Faisal Vali a eu accès à la nouvelle terminologie sur les Deduction Guides. On en reparlera après dîner.


2191. Incorrect result for noexcept(typeid(v))

On a examiné cette chose plus tôt cette semaine. Le problème est que :

struct B { virtual void f() { } };
struct D : B { } d;
bool b = noexcept(typeid(d));

... ne peut pas lever d'exception, donc b devrait être false, or ceci rapporter pouvoir lever une exception. La terminologie proposée corriger l'irritant.

Class Template Argument Deduction Assorted NB resolution and issues

Faisal Vali donne un peu de contexte. Ça vise US19 et US20 : US19 porte sur le fait qu'on veut que les Deduction Guides aient précédence sur les formes implicites équivalentes; US20 vise à clarifier un cas d'ambiguïté quant aux initialisations directes.

Jens Maurer demande de retravailler un exemple pour qu'il évite les traits de la bibliothèque standard et s'en tienne à du code Core.

On suspend les travaux vers 12 h pour dîner. C'est bon : tortillas, porc ou poulet effilochés, salade, ingrédient pour s'assembler des tortillas, riz espagnol, purée de fèves, et des petits churros farcis pour dessert (les desserts sont bons mais trop lourds pour moi ici; je les prends à cause de mon budget, mais sinon je pense que je passerais... Mon corps n'est pas habitué aux gros dîners, et ça m'assomme pour l'après-midi de « manger lourd » comme ça).

Petite jasette avec Lawrence Crowl à propos de l'infinité et du standard. Pas sûr que j'ai réussi à bien communiquer les enjeux, mais on aura d'autrs occasions (moins bruyantes) d'en discuter.

Je prends le Wiki car Jens Maurer va à LWG

Modules

D0512R0: Class Template Argument Deduction Assorted NB resolution and issues

D0003R5: Removing Deprecated Exception Specifications from C++17

Alisdair Meredith : j'ai ajouté un terme de grammaire pour noexcept-specifier. Ensuite, dans §15.4p3, pour les cas où nous n'avons pas de spécification d'exception ou s'il y a de la confusion, j'ai compris que leur absence tenait à une position de CWG dans le passé. Ça laissait les destructeurs et les fonctions de déallocation.  Il y avait aussi de la terminologie dans §15.4 qui me semblait correcte et que je n'ai pas remplacée.

Richard Smith : dans §15.4p3, on a un résidu de ce dont on souhaite se débarrasser. Aussi, on a un if qui devrait être if and only if, pour marquer l'obligation.

Alisdair Meredith : ça nous mène à une surcharge sur la base de la spécification d'exception, ce qui est illégal.

On apprend quelque chose à chaque jour : à notre surprise collective, il est possible de déclarer une fonction virtuelle =delete et de la spécialiser, dans la mesure où les spécialisations sont =delete aussi. Oui, je sais...

Richard Smith : il ne vaut pas la peine de demander à une fonction spéciale sa spécification d'exception si elle est =delete.

Mike Miller fait remarquer que les correctifs à typeid déterminés ce matin doivent se refléter dans ce cas.

(c'est un gros document, alors on fait des tas de retouches mineures ici et là)

Davis Herring : mon patron m'a déjà dit « No one really knows C++; they practice it like medicine » (on rit!)

Jason Merrill : faudrait écrire un système expert pour le langage

Richard Smith : n'est-ce pas ce que nous faisons? (rires!)


Mike Miller nous indique que US98 n'est plus un NB Comment. La personne l'ayant soumis a concédé que ce « problème » était dû à un problème de compréhension.

Richard Smith : j'ai ajouté une proposition nommée decrement-bool (un fichier .png, rien de moins!).

On le regarde. C'est un extrait d'une annexe. Ça indique qu'en C++, il est interdit de faire --b ou b-- si b est un bool.

Jens Maurer se demande si on devrait joindre ++ et -- pour bool dans une même section. Richard Smith pense qu'il est préférable de marquer ++ comme un bris de compatibilité avec C++ 14 et -- comme un cas d'incompatibilité avec C. On discute des mérites des deux approches... On y va tel quel.

Pause vers 15 h 17. On apprend en sortant que la proposition de Hubert Tong et de Faisal Vali à propos des références intelligentes par voie de délégation a reçu un encouragement fort chez EWG, ce qui est un intéressant développement étant donné que ça joue dans la même cour, à toutes fins pratiques, que la surchage de l'opérateur « . » qui est un sujet contentieux. Évidemment, les co-auteurs sont ravis.

On reprend les travaux avec Walter E. Brown et les clauses requires

P0266R2: Lifting Restrictions on requires-Expressions

Hubert Tong indique qu'il contactera Andrew Sutton pour l'informer de la résolution des quelques Issues que cette proposition corrige.

On l'envoie pour vote vendredi.

D0315R2: Lambdas in unevaluated contexts

Louis Dionne vient nous rejoindre. Il fait une brève mise en situation des raisons pour la restriction à l'origine, et des raisons selon lui pour la lever.

Hubert Tong rappelle les raisons à l'origine des restrictions du point de vue ce Core. Il dit qu'on a déjà eu des demandes semblables; en supprimant les restrictions en question, ça ouvre la porte à l'écriture de template switches qui sont équivalentes mais pas fonctionnellement équivalentes. On pensait ouvrir un Core Issue mais on n'a pas de guidance d'EWG en ce sens.

Louis Dionne dit qu'il sera heureux si ça va dans C++ 17 mais ne comptait pas là-dessus.

Faisal Vali : est-ce qu'EWG accepterait qu'on en fasse en DR?

Richard Smith : aucune idée.

Richard Smith : ce qui retient ceci est une considération de linkage, où notre texte n'est pas très fort pour le moment. Il y a aussi la question du ODR... On peut difficilement construire sur quelque chose d'incorrect, car on va le détruire quand on corrigera le bogue existant.

Jens Maurer : tu dis que les règles de linkage des λ sont incorrectes?

Richard Smith : oui. On a des fonctions auto qui retournent des λ ce qui fait des λ une partie de leur type, mais elles n'ont pas de linkage. C'est vraiment utile.

Jason Merrill : on peut utiliser de telles choses en pratique.

Richard Smith : par contre, les templates générés sont des mensonges.

Hubert Tong : il faut que les implémentations, pour être de qualité, aillent à l'encontre du texte du standard.

Hubert Tong : on veut donc changer la règle qui empêche les cas « mauvais », sans les permettre...

Richard Smith : dans la proposition, les λ aux puces 2 et 3 devraient avoir du linkage selon moi.

Hubert Tong : on peut leur donner du linkage sans changer les règles d'ODR.

Jens Maurer : il serait utile de retravailler la présentation du document pour faciliter les suppressions et les ajouts.

Richard Smith trace la ligne entre les cas de templates dépendants et non-dépendants. Peut-on faire du SFINAE dans ce cas?

Jens Maurer : oui, c'est drôlement placé.

Richard Smith : le mot « unique » est ambigu ici. Il faudrait quelque chose comme « unique acrosss all instantiations ».

Richard Smith : dans la section 6, la note deviendra sans doute du texte normatif, alors aussi bien le faire tout de suite.

RRichard Smith : je pense que la stratégie se tient. On aura d'une pierre deux coups.

Jens Maurer : quelle sera la stratégie en pratique?

Hubert Tong : une fois que la question du linkage sera réglée, ça devrait bien aller.

Jens Maurer :: donc notre stratégie sera de permettre les λ partout, mais pas de les laisser déborder dans l'éditeur de liens.

Quelques échanges s'ensuivent sur la subtilité pour laquelle il n'est pas grave actuellement d'utiliser une λ dans un algorithme standard. Je vous passe les détails, mais on fait un peu de magie et c'est très amusant, et ça explique de la mécanique subtile comme le concept de namespace anonyme et sa conséquence sur l'éditeur de liens.

Jens Maurer : comment articule-t-on le texte normatif nécessaire pour empêcher les λ de « couler » dans la surface d'exposition à l'éditeur de liens? Hubert Tong lui explique qu'on peut se baser sur [temp.over.link] et profiter de la distinction entre équivalent et fonctionnellement équivalent. On examine le texte proposé. Il y a un cas d'interaction avec ces signatures dans un cas de classe template qui impose une identité de code généré et qui exige des règles un peu particulieres de redéclarations. Hubert Tong pense que les adaptations du texte normatif tel que proposé, sans être toutes nécessaires, sont plus future-proof que le texte existant. Richard Smith propose qu'on garde ce passage en tête alors et qu'on attende que le besoin survienne avant de faire des changements additionnels.

Hubert Tong : nous allons réécrire le paragraphe 6 et alléger le volet linkage, puis nous présenterons la prochaine itération de manière à faciliter le suivi des changements.


Mike Miller souhaite qu'on redistribue des tâches de drafting assignées à des gens qui ne viennent plus aux réunions. Jens Maurer demande si on devrait commencer par relancer les gens qui sont plus ou moins actifs pour savoir s'ils comptent s'y remettre ou non.

1565. Copy elision and lifetime of initializer_list underlying array

La question est de savoir si ce qui suit provoque une copie et étend la vie de l'objet :

void f() {
  std::initializer_list<int> L =
    std::initializer_list<int>{1, 2, 3}; // Lifetime of array extended?
}

NAD car désormais, c'est un constructeur, pas une copie.

1924. Definition of "literal" and kinds of literals

Ceci semble avoir été réglé de manière éditoriale.

1721. Diagnosing ODR violations for static data members

Il semble y avoir une résolution qui remonte à Chicago en 2013.

2187. Protected members and access via qualified-id

Hubert Tong explique : ça fonctionnait, ça ne fonctionne plus, faut l'arranger. Hubert Tong, P0.

2188. empty-declaration ambiguity

Jens Maurer : il y a deux règles grammaticales distinctes qui mènent à empty-declaration. Jens Maurer, P3.

2189. Surrogate call template

Jason Merrill explique :

template <class T>
   using Fn = void (*)(T);
struct A {
   template <class T>
   operator Fn<T>();
};
int main() {
   A()(42);
}

13.3.1.1.2 describes how conversion functions to pointer/reference to function work in overload resolution, but is silent about conversion function templates. Generalizing the wording there, in this case we could generate a surrogate conversion template

template <class T>
   void /surrogate/ (Fn<T> f, T a) { return f(a); }

which would work as expected. But it seems that implementations don't actually do this currently. Is this a bug or an extension?

On le laisse sans priorité pour le moment. Jason Merrill va y réfléchir.

2190. Insufficient specification of __has_include

Hubert Tong indique que ceci :

#define X <ciso646> )
#if __has_include( X && *(* defined(X) )
#endif

...serait bien formé mais trop agressif dans la réécriture. Mike Miller se demande si ça nous concerne. Jens Maurer dit qu'il n'irait pas plus loin qu'adapter la terminologie pour réduire la divergence entre les implémentations. Mike Miller suggère une priorité faible pour ça, et on réévaluera au besoin. P3.

2174. Unclear rules for friend definitions in templates

Richard Smith a de la terminologie à proposer pour celle-là. Son exemple est du bonbon :

template <typename T> struct Friendly {
  friend void f(int) {}
};
Friendly<int> fi;
Friendly<float> ff; // ill-formed: produces second definition of f(int)

David Herring demande comment on pourrait référer à f(int). Richard Smith explique un truc. On se bidonne.

Thomas Köppe demande si cette résolution rejoint la pratique existante; il dit l'avoir essayé avec g++ et Clang et les deux rejettent l'exemple tel qu'annoncé. Richard Smith explique que ça s'applique à tous les amis d'une classe template. Il propose d'ajouter un exemple reposant sur un template lui aussi, pour clarifier le cas où il y a variation dans les implémentations :

template <typename T> struct Friendly {
  template<typename U> friend int f(U) { return sizeof(T); }
};
Friendly<int> fi;
Friendly<float> ff; // ill-formed: produces second definition of f(U)

C'est pas mieux. On en fait un cas Ready.

Core Issue 1721: Diagnosing ODR violations for static data members

Dawn Perchik, à distance, nous envoie le texte de la résolution qui dit, simplement, no diagnostic required. Mike Miller n'est pas certain que ce soit suffisant. Jason Merrill craint le fait qu'il y ait deux contraintes dans la même phrase et que l'on préfère no diagnostic required pour la partie ODR mais pas pour l'autre partie. Richard Smith estime que la première partie de l'énoncé devrait n'être qu'une note, et qu'on devrait retirer le shall qui est contraignant.

On ferme à 17 h 30. Grosse journée encore.

Retour à la chambre, petit bonjour à mon amoureuse... J'apprends le décès de Leonard Cohen. Ouch. Celle-là fait mal.

Je corrige quelques copies, un peu déprimé, puis je me sers un scotch de la petite bouteille reçue en cadeau à Amsterdam. Cette petite bouteille m'aura fait six verres au total pendant la semaine, mais ils auront été bien agréables.

Vers 20 h, heure locale, la rencontre de SG7, groupe d'étude sur sur la réflexivité dirigé par Chandler Carruth, débute.

À mon arrivée, la salle est bien garnie (il doit y avoir plus de 40 personnes) et David Sankel commence à présenter. C'est un projet sérieux que celui mis de l'avant ici : une architecture à quatre couches, dont on défend ce soir les préceptes fondamentaux (le reste pourrait être proposé ultérieurement). Ça repose sur les travaux de Matúš Chochlík : http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0385r1.pdf. On s'accroche parfois dans les fleurs du tapis pour des trucs qui ne sont pas au coeur du propos, ce qui est un peu triste, mais ça arrive dans une rencontre d'experts que les gens accrochent sur des détails périphériques. Évidemment, avec une facilité de métaprogrammation statique poussée, considérant le calibre des experts dans la salle, chaque petit détail susceptible d'accrocher va accrocher. En ce sens, Chandler Carruth fait un bon travail et intervient.

Louis Dionne vole ensuite un peu le show en montrant comment Boost.Hana peut prendre le code de la présentation et faire de petits miracles. Ça attire l'attention  Je pense que la direction qui sera prise mettra de l'avant l'infrastructure de la proposition mais la syntaxe de Louis Dionne. Même Herb Sutter est intervenu pour indiquer qu'il y aura des métriques de faites d'ici Kona et qu'une discussion chiffrée suivra. On prend quelques votes et ça va très clairement dans cette direction. On enchaîne sur une discussion en vue d'un TS de métaprogrammation, probablement influencé par les idées de Louis Dionne.

Ce fut une belle rencontre de deux heures ou presque, riche en contenu.

Jour 4 11 novembre 2016

Ce matin, Leonard Cohen joue partout. Un brin d'éternité.

Je parle un peu à mon amoureuse en préparant ma journée. Za, tu me manques. Je repars vers toi et les enfants demain, et j'ai hâte.

Quelques étudiant(e)s ont besoin d'aide, alors je traite les courriels du jour.

Comme c'est l'habitude lors des rencontres de WG21, notre journée aujourd'hui suivra en gros le patron suivant :

C'est donc une journée pleine d'inconnues encore, et où il pourrait y avoir des rebondissements. Parfois, en diplomatie, il survient des arrangements de dernière minutes qui peuvent transformer complètement le portrait de la situation...

On s'installe, on blague un peu sur le côté radicalement sucré des desserts (je ne suis pas le seul dont le corps n'est pas habitué à cette quantité de sucre dans la salle), et on se prépare pour les derniers textes de la semaine.

On reprend les travaux sur les ajustements faits en réponse aux NB Comments. Mike Miller nous explique le plan de match pour la matinée. La liste est longue, je ne pense pas qu'on pourra tout traiter, mais il y a de l'espoir pour quelques gros dossiers comme la TS sur les coroutines, les spécifications dynamiques d'exceptions et std::byte (liste non-exhaustive).

GB 26: 'last' active handler and multithreading

Jens Maurer nous explique que Hans Boehm a fait un (très) petit changement qui améliore le texte. On accepte.

DR: Matching of template template-arguments excludes compatible templates

Hubert Tong dit qu'avec template <auto> (de James Touton), on a découvert un truc surprenant. En grattant, on a découvert que ça couvrait Core Issue 150, alors qu'il y avait une double motivation pour retravailler la terminologie et le permettre. En pratique :

template <template <int> class> void FI();
template <template <auto> class> void FA();
template <auto> struct SA { /* ... */ };
template <int> struct SI { /* ... */ };
FI<SA>();  // OK; error before this paper
FA<SI>();  // error

template <template <typename> class> void FD();
template <typename, typename = int> struct SD { /* ... */ };
FD<SD>();  // OK; error before this paper (CWG 150)

Jens Maurer fait remarquer que ça rend vector un cas possible de template <auto>, un effet de bord plutôt sympathique. On discute un peu pour voir si on peut en faire un DR contre C++ 14 et l'intégrer pour C++ 17, ou si ça doit attendre à C++ 20. Mike Miller fait remarquer que pour que ça soit un DR contre C++ 14, faudrait faire disparaître template <auto> de la résolution puisqu'avec C++ 14, ça n'existait pas.

On travaille un peu la terminologie. L'idée est d'ajouter le concept qu'un « template template-parameter P » soit au moins aussi spécialisé qu'un « template template-argument A ». Jason Merrill mentionne que quand le TS des concepts va être sur le point d'être accepté, ceci va demander une réflexion à savoir comment les deux idées de rejoignent ou se confrontent.

Richard Smith expose une crainte dans le cas des alias templates. Il donne un exemple :

template<typename T, int N = 5> using X = T;
//                   ^^^^^^^^^
int n;
template<template<typename, auto> typename T> struct A {
  //                        ^^^^
  T<int, &n> t;
  //     ^^
};
A<X> a; // la crainte serait l'interprétation ici. Faudrait que ça échoue, mais c'est pas clair avec la terminologie proposée

On travaille la terminologie une bonne demie-heure. On parle de template template parameters, ce qui élève doublement le niveau d'abstraction et rend le concept de paramètre ambigu (auquel des niveaux d'abstraction s'adresse-t-on?). À un moment donné, dans un bloc de trois phrases, le mot template apparaît dix fois dans la première et sept fois dans la troisième...

On soumet ça au vote cet après-midi, en tant que DR contre C++ 14 en version épurée de template <auto>. Ça devient P0522R0.

D0298R2: A byte type definition

Mike Miller fait le tour des (rares) modifications au document. Ça règlerait US72 entre autres.

Thomas Köppe demande si on ajoute un truc à <cstddef> mais pas à <stddef.h>. Ce serait un pas en avant. Ça ne semble pas causer de malaise dans la salle.

Thomas Köppe fait remarquer que la table 30 devrait être supprimée, n'étant plus dans le standard. On ne peut pas faire ça nous-mêmes, car ça tombe dans la zone du standard sous la gouverne de LWG.

Il reste une note à retirer et des retouches éditoriales, puis c'est prêt. On soumet ça au vote cet après-midi si LWG arrive à le traiter.

Editorial 522: [basic.life] Fix Modal Verb

https://github.com/cplusplus/draft/pull/854/files

L'idée est de clarifier le fait que ceci soit incorrect :

struct A {
  const int n;
  ~A() { printf("%d", n");
};
void f() {
  A a = {4};
  a.~A();
  new (&a) A{5};
} // ici, a.~A(); est un cas de comportement indéfini

Jens Maurer pense qu'on doit en faire un Core Issue. Le texte actuel n'est pas correct sur le plan normatif.

Core Issue 1622: Empty aggregate initializer for union

Patrice Roy demande ce qui se passe si deux membres ont un default member initializer. Richard Smith indique que le programme est alors malformé.

La terminologie demande une ou deux mini retouches mais elle est acceptée. On la présentera formellement à Kona.

Pause vers 10 h 15. Pendant la séance du matin, il y a eu de l'action sur les listes de discussion à propos de considérations de nommage, de subtilités techniques, d'enjeux politiques... Un reçoit une visite d'EWG, car une proposition pour permettre d'avoir une liste de paramètres incluant des variadiques qui ne termine pas par le variadique sera débattue et que c'est le genre de concept avec lequel on tend à jongler ici. Ça brasse. Il y a des courriels de mécontentement qui circulent à l'effet que nous bloquerions le progrès dans certains dossiers. Il n'y en aura pas de facile...

Pendant la pause, Richard Smith a produit un exemple du problème de clarté avec le modules TS tel que proposé :

module A;
export template<typename X, typename Y, typename Z> void f(X x, Y y, Z z) {
  g(x);
  g(y);
  g(z);
}

module B;
import A;
export struct X {};
export void g(X);
export template<typename Y, typename Z> void f(Y y, Z z) {
  f(X(), y, z);
}

module C;
import B;
export struct Y {};
export void g(Y);
export template<typename Z> void f(Z z) {
  f(Y(), z);
}

// ----
import C;
struct Z {};
int main() {
  f(Z());
}

Tel que décrites par le TS, les règles rejettraient ceci pour des raisons de visibilité du module B (ADL ne trouverait pas g(X)), pourtant l'exemple semble raisonnable. Aussi, les règles actuelles ne permettent pas un truc comme ceci :

module X;
import std.utility;
import C;
template<typename T> void f() {
  std::pair<T, Y> p;
}

// ----
import X;
void g() { f<int>(); }

...où Y n'est pas exporté par X, mais où sa définition doit être visible par l'instanciation du constructeur par défaut de pair pour que le tout fonctionne.  Il manque de précision dans les règles en vigueur pour que les implémenteurs sachent quoi faire dans de tels cas et pour éviter que les implémentations ne divergent.

Removing Deprecated Exception Specifications from C++17

Alisdair Meredith est de retour. Certains des ennuis auxquels il fait face on trait à des résolutions de Core. Par exemple, Core Issue 2191, que nous pensons avoir réglé cette semaine.

Jens Maurer fait le tour des trucs à ajuster, et Alisdair Meredith applique les correctifs résiduels. On fait beaucoup, beaucoup de petits trucs, mais on aimerait aussi beaucoup, beaucoup que ce soit un dossier clos pour C++ 17. On parle d'une trentaine de minutes de retouches et de clarifications diverses ici. On est assez contents du résultat.

On soumet ça au vote cet après-midi.

Core Issue 1677: Constant initialization via aggregate initialization

Richard Smith explique qu'on cherchait auparavant à exprimer quelque chose de relativement simple, mais d'une manière relativement compliquée car, faute d'une entité grammaticale convenable, on s'empêtrait dans les cas particuliers. L'ajout du terme full-expression par Jens Maurer permet de simplifier significativement la terminologie, et de la clarifier.

Hubert Tong exprime une réserve quant à la nature quelque peu élusive du terme expression dans le texte du standard pour le moment. Cela dit, le nouveau est est significativement meilleur que le précédent.

On la présentera formellement à Kona.

P0329R2: Designated Initialization Wording

Tim Shen a changé la définition de explicitly initialized element pour tenir compte des union anonymes. En retour, son design global demeure tel quel.

J'ai dû partir chez SG1 pour présenter la proposition de Vicente J. Botet Escribá, alors j'ai perdu le fil des travaux de CWG pour la dernière demie heure de l'avant-midi, mais voici les grandes lignes de ce que j"ai raconté :

Au total, donc : réception positive, et peut-être un mécanisme pour C++ 20 qui sera utile à la communauté SG14, mais je ne sais pas encore quelle forme cela prendra.

Quand je suis revenu chez CWG prendre mon ordinateur et ma tasse de café, j'ai pu constater que durant mon absence, le travail s'est poursuivi sur la terminologie de P0329R2.

Le dîner comprenait du poisson pané (vendredi oblige, je présume; je l'aurais préféré sans panure, mais bon), crevettes panées (idem), frites, salade, desserts (sucrés, mais il y en avait un moins lourd – au moins en apparence – parce qu'au citron). Je me suis permis une bière parce que nous devions discuter de nos positions communes en cas de contentieux. Nous avons une délégation assez forte ici, dix personnes avec une diversité d'expertise intéressante et des personnalités affirmées. Les quelques enjeux clés qui nous concernent sont très techniques, alors je vous les épargne ici, mais ils influenceront nos votes et, dans certains cas, la manière par laquelle nous négocierons certains ajustements cet après-midi.

Je suis ensuite allé à ma chambre pour me rafraîchir et informer Vicente J. Botet Escribá que j'ai présenté sa proposition et qu'elle m'a semblé être bien reçue, même si SG1 n'a pas pris de vote encore (préférant attendre à demain matin).

Nous reprenons les travaux vers 14 h 30 en plénière. Évidemment, la salle est pleine.

Clark Nelson prend la parole. On commence par faire le tour des groupes d'étude.

Michael Wong : SG5 ne s'est pas rencontré cette semaine.

Lawrence Crowl : SG6 s'est rencontré. On pense pouvoir assembler un WD d'outils numériques. On a passé en revue plusieurs NB Comments, portant sur les NaN et l'infinité. Walter E. Brown a proposé un document sur le futur des numériques et un autre sur une éventuelle TS pour random. Herb Sutter : c'est habituellement EWG qui commande les TS. Passerez-vous par là? Lawrence Crowl : oui.

Chandler Carruth : SG7 s'est rencontré. La réflexivité statique avance bien. On veut expérimenter avec un TS d'abord. Ce qu'on a vu fonctionne et semble excitant. On compte faire des retouches à Kona puis se mettre à un document. On a aussi vu de nouvelles approches pour ce qui est des API.

Clark Nelson : SG10 ne s'est pas rencontré

Gabriel Dos Reis : SG12 ne s'est pas rencontré

Michael Wong : SG14 s'est rencontré à CppCon 2016, nous étions une soixantaine (et les gens payaient pour y être), et plusieurs des propositions discutées là-bas ont été portées cette semaine.

Herb Sutter : SG13 s'est rencontré mercredi soir. On a passé une proposition en revue, et on n'a pas de proposition à porte en plénière cette semaine.

Hans Boehm : SG1 s'est rencontré toute la semaine durant. L'une de nos positions clés est de maintenir la situation d'appeler std::terminate() lors d'une exception pendant une exécution parallèle, mais nous avons associé le comportement à la politique d'exécution alors ça pourrait changer dans le futur. On a aussi retouché quelques trucs agaçants comme shared_ptr<T>::unique(). On pense voir les exécuteurs apparaître bientôt, car le dossier a fortement progressé cette semaine. Les distinction entre les travaux des TS sur la parallélisme et sur la concurrence s'amenuisent avec le temps alors on pense éventuellement les fusionner.

Ville Voutilainen : EWG a traité les NB Comments sur la table. Les discussions sur les modules et sur les concepts reprendront à Kona. Nous n'avons pas de proposition a passer de toute urgence cette semaine alors ce qui doit être relayé à CWG le sera d'ici Kona. Je veux attirer l'attention sur la proposition de Hubert Tong pour une manière alternative de réaliser des références intelligentes; cette proposition a amassé beaucoup de support et sers discutée à nouveau à Kona. Certaines propositions pour prendre un pointeur sur un attribut domt le type est une référence sont apparues sur le radar. Alisdair Meredith : et les opérateur de comparaison? Ville Voutilainen : nous ne sommes pas encore parvenus à approcher d'un consensus.

Neil MacIntosh : merci à LEWG de m'avoir laisser remplacer Jeffrey Yasskin cette semaine. Nous avons couvert environ 85 propositions cette semaine, quelques-unes que nous avons rejeté, et nous avons commencé à survoler les nouvelles propositions pour C++ 20.

Mike Miller prend ensuite le plancher. En plénière, les propositions à voter viennent typiquement d'en haut (LWG) ou d'en bas (CWG). Notre principale responsabilité était de traiter les NB Comments dirigés vers C++ 17, et nous avons profité du triage initial réalisé par Jens Maurer et VVille Voutilainen. Se sont ajoutées quelques propositions pour C++ 17 qui nous avaient échappé à Oulu pour des raisons administratives, particulièrement les using variadiques, la suppression des spécifications dynamiques d'exceptions, std::byte, etc.

Mike Miller : nous avons aussi examiné plusieurs fois les modules, pour lesquels nous avons résolu quatre Issues. Selon nous, les modules ne sont pas prêts pour PDTS mais nous avons bon espoir qu'ils le soient à Kona. Nous avons examiné les travaux de Walter E. Brown sur une partie du TS des concepts. Nous avons aussi travaillé avec Gor Nishanov pour le TS sur les coroutines.

Mike Miller : nous adresserons aujourd'hui 23 NB Comments, nous avons deux rejets, quatre délégués à d'autres groupes, et sept sur lesquels il nous reste du travail à faire. Botond Ballo : les extensions aux modules visent-elles le PDTS? Ville Voutilainen : non. Marshall Clow : puis-je faire ceci?

template <class ...Ts>
   struct X{
      using ts = remove_cv_t<Ts>...;
   };

John Spicer : non, mais (explique les détails).

Une motion de la salle : nous voulons un rapport de progression du traitement des NB Comments. (confusion s'ensuit...) Nous souhaitons avoir un tel rapport pour être mieux en mesure de savoir si nous avons oublié quelque chose. Marshall Clow : j'ai déjà créé une page sur le Wiki de Kona; elle est vide pour le moment mais on la tiendra à jour alors elle devrait être pas si mal dans une semaine. De la salle : demande des précision sur la procédure dans un tel cas. Herb Sutter explique que la procédure ISO fonctionne pas consensus, pas par des règles comme celles d'assemblées générales. Mike Miller explique comment il assure habituellement le suivi dans ces cas, mais dit apprécier l'approche par Wiki considérant la taille de WG21. Beman Dawes : nous avons un Admin Reflector pour discuter efficacement de ces trucs; je préférerais que ce soit discuté dans une tribune où ce sera plus efficace.

Marshall Clow : nous avons eu une semaine occupée, essentiellement avec les NB Comments, sur la base des efforts de Jens Maurer et Ville Voutilainen. Nous avons traité environ 40 Library Issues et 70 NB Comments. On a eu environ 50 NB Comments spécifiquement sur <filesystem>.

Beman Dawes : nous avons eu une excellente semaine; nous n'apportons pas de propositions pour fins de vote aujourd'hui, mais nous les apporterons à Kona. Nous sommes d'avis que plusieurs sont interreliées et nous allos les amener de manière cohérente. Aussi, <filesystem> est lié de près au système d'exploitation, et après avoir eu du soutien de Microsoft et de POSIX depuis longtemps, nous avons cette fois en plus eu droit à un spécialiste d'un autre, immense système différent de ceux-ci. Ça nous rend confiants que notre design fonctionne. Un problème était que nous avions environ 60 NB Comments sans proposition terminologique, et que nous ne pouvions pas raisonnablement toutes les refuser. Nous pensons apporter quatre propositions omnibus à Kona. Les propositions tardives ont été évitées cette semaine, la priorité étant ailleurs, mais il y en a un peu moins d'une dizaine que nous avons traité en passant.

Marshall Clow : nous avons aussi fait une revue terminologique de TS, et nous vous présenterons celles de networking, , des coroutines et des intervalles.

Petite pause. Calypso m'a écrit pour me demander ma recette de couscous, alors je la lui donne. Je me sers un café et on reprend pour les votes.

On reprend avec les motions de CWG. Herb Sutter comment en réexpliquant les règles de votation.

CWG Motions

Motion 1 Move to accept as Defect Reports the issues in P0519R0 (Core Language "ready" issues) and apply their proposed resolutions to the C++ working paper.

Unanime

Motion 2 Move to accept as Defect Reports the issues in P0520R0 (Core Language "tentatively ready" issues) and apply their proposed resolutions to the C++ working paper.

Unanime

Motion 3 Move to accept Core Language issue 1343 as a Defect Report and apply the resolution in P0507R0 to the C++ working paper.

Unanime

Motion 4 Move to accept Core Language issue 150 as a Defect Report and apply the resolution in P0522R0 to the C++ working paper.

Unanime

Motion 5 Move to apply to the C++ working paper the proposed wording in core clauses in P0003R5 ("Removing Deprecated Exception Specifications from C++17").

Mike Miller dit que le plan ici est de passer le volet Core par une CWG Motion et la partie Library par LWG Motion.. Alisdair Meredith craint que la proposition ne soit à moitié rejetée. Clark Nelson n dit que c'est son idée. Mike Miller dit que si ça accroche, on fera une motion pour reprendre la partie Core.

Unanime

Motion 6 Move to apply to the C++ working paper the proposed wording in P0490R0 ("Core language changes addressing National Body comments for CD C++17").

Unanime

Motion 7 Move to apply to the C++ working paper the proposed wording in P0195R2 ("Pack expansions in using-declarationss").

Nicolai Josuttis demande si c'est une nouvelle proposition. Mike Miller dit que c'est de petites retouches à une proposition traitée antérieurement

Unanime

Motion 8 Move to apply to the C++ working paper the proposed wording in P0512R0 ("Class Template Argument Deduction Assorted NB resolution and issues").

Unanime

Motion 9 Move to apply to the C++ working paper the proposed core wording in P0298R2 ("A byte type definition").

Mike Miller : nous ne présentons que la partie Core du document, car le volet Library a beaucoup changé et LWG souhaite l'adapter en vue d'une adoption à Kona. Nicolai Josuttis fait remarquer que le type vient de la section Library. Mike Miller se demande si on devrait retirer cette motion. Richard Smith dit que sur le plan éditorial, on pourrait le passer aujourd'hui. Gabriel Dos Reis demande des précisions. Richard Smith dit qu'on a échappé une table référée dans le document mais qui n'existe plus. Jens Maurer dit qu'on peut passer la partie Core aujourd'hui ou tout passer à Kona tout simplement. Nicolai Josuttis demande si Library en a parlé. Marshall Clow dit que ça a été discuté à Oulu après les votes, et que ça a été adopté. Herb Sutter dit qu'on peut souvent passer la proposition et corriger le reste de manière éditoriale a posteriori. Mike Miller dit qu'on a allumé tard ce matin et qu'on peut changer de plan. Tom Plum pense qu'on devrait approuver là et corriger le reste de manière éditoriale. Beman Dawes dit que l'éditeur de projet peut rejeter une proposition avec volet « éditorial » s'il constate que ça ne fonctionne pas. Nicolai Josuttis demande des précisions. Davis Herring explique qu'à la manière de std::typeinfo, c'est un type Library qui sert à Core pour raisons de propriétés particulières. Nicolai Josuttis suggère qu'on aille de l'avant.

Une membre de l'audience s'oppose au nom choisi, le considérant problématique (ça ne ressemble pas aux types byte existant) et estimant que ça ne standardise pas la pratique existante. Le fait d'ajouter un nouveau type représentant un byte, mais qui ne devrait pas être utilisé comme un nombre, pose problème. Selon lui, ce n'est pas un mauvais type, mais le type lui semble mal nommé. On rappelle que LEWG en a discuté cette semaine. D'autres estiment qu'il y a du support affiché pour le nom. La personne qui dirigeait LEWG au moment des échanges dit que la discussion fut brève et que le nom n'a pas posé problème. Quelqu'un trace un parallèle avec std::launder(), qu'on aime généralement voir les gens éviter parce que c'est subtil, mais que se servir de std::byte peut surprendre si le comportement ne correspond pas aux attentes. Mike Miller explique l'intention derrière std::byte en tant qu'espace d'entreposage plutôt qu'en tant qu'unité de calcul. Quelqu'un explique sa perspective selon laquelle un byte est un concept non-arithmétique justement. Herb Sutter rappelle que le nom ne sera pas choisi en plénière, et qu'il est possible de voter contre le nom.

Pas de consensus. On devra réétudier la question dans le futur. Herb Sutter valider avec la salle et ce qui semble clair est que le problème est le nom, pas le type.

Motion 10 Move to accept as Defect Reports the issues in P0500R0 and apply their proposed resolutions to the Modules TS working paper.

Unanime

Motion 11 Move to apply to the Concepts TS working paper the proposed wording in P0266R2 ("Lifting Restrictions on requires-Expressions").

Un membre de l'audience critique cette proposition à l'effet qu'elle contourne le portrait plus global des concepts plutôt que d'aider à faire avancer cette cause. Un autre pense au contraire que la proposition tend en fait à alléger la syntaxe des concepts. L'auteur se dit d'avis que la proposition est bidirectionnelle : elle introduit les concept comme une entité de première classe, et développe une habitude à l'usage des clauses requires; selon lui, ce que ceci fait aujourd'hui est de simplifier le langage pour réduire le recours à enable_if. Techniquement, la proposition ne contient que très peu de modifications en comparaison avec le texte débattu lors de rencontres antérieures, et résout un problème dans la TS de concepts. Certaines personnes critiquent l'absence dans la salle des tenants des concepts. Jason Merrill fait remarquer que g++, le seul compilateur supporant les concepts. supporte déjà ce que soutient cette proposition et que ça fonctionne bien. Casey Carter, qui utilise beaucoup les concepts parce qu'il est l'éditeur du ranges TS, soutient que ce mécanisme l'aurait beaucoup aidé et lui aurait sauvé des milliers de lignes de code.

Consensus.

LWG Motions

Motion 1 Move to modify the LFTS V2 working paper with the NB comment responses in N4616 (NB Responses PDTS 19568 2 Collated Comments).

Consensus

Motion 2 Move to modify the LFTS V2 working paper the proposed wording in P0253R1 (Fixing a design mistake in the searchers interface in Library Fundamentals).

Unanime

Motion 3 Move to appoint an editing committee composed of Marshall Clow, Geoffrey Romer, and Daniel Krügler to approve the correctness of the LFTS V2 working paper as modified by the motions approved at this meeting, and to direct the Convener to transmit the approved updated working paper for publication.

Unanime

Motion 4 Move to modify N4560 - Ranges TS by applying P0370R2 (the changed parts were reviewed at this meeting) and P0022R2 - Proxy Iterators for the Ranges Extensions (which was reviewed in Oulu) and P0441R0 - Merging Writable and MoveWritable (which was reviewed this week).

Unanime

Motion 5 Move to appoint an editing committee composed of Eric Niebler, Casey Carter and Marshall Clow to approve the correctness of the Ranges working paper as modified by the motions approved at this meeting, and to direct the Convener to transmit the approved updated working paper for PDTS ballot.

Un membre de l'audience valide que ce document dépend du concepts TS. Marshall Clow confirme que tel est le cas.

Unanime

Motion 6 Move to modify N4612 - Networking TS by applying P0405R0 (reviewed in Chicago) and P0423R0 (Variable templates for Networking TS traits; reviewed in Chicago).

Unanime

Motion 7 Move to appoint an editing committee composed of Jonathan Wakely, Chris Kohlhoff and Lars Gullik Bjønnes to approve the correctness of the Networking TS working paper as modified by the motions approved at this meeting, and to direct the Convener to transmit the approved updated working paper for PDTS ballot.

Unanime

Motion 8 Move to direct the convener to request a new work item for a Technical Specification on C++ Extensions for Coroutines and create a working paper with P0057R7 ("Wording for Coroutines") as its initial content.

Consensus

Motion 9 Move to appoint an editing committee composed of Geoffrey Romer, Dinka Ranns, Gor Nishanov and James Denning to approve the correctness of the Coroutines TS working paper as modified by the motions approved at this meeting, and to direct the Convener to transmit the approved updated working paper for PDTS ballot.

Pas de consensus, mais c'est limite. La résistance semble tenir au fait que les approches alternatives ne sont pas encore prêtes pour inclusion, et que certains veulent examiner ces approches de plus près. Herb Sutter demande à Mike Miller comment assurer le suivi du dossier. On reprendra le vote à Kona pour que les gens aient l'opportunité de faire avancer leurs dossiers. Jens Maurer fait remarquer que l'interface entre Core et Library est vaste et que dans un monde idéal, on la réduira d'ici lors.

Motion 10 Move to apply to the C++ working paper all of the issues (one) in P0304R1 (C++ Standard Library Issues Resolved Directly In Issaquah). This is issue #2770, which is the only P1 issue remaining.

Unanime

Motion 11 Move to apply to the C++ working paper all of the issues in P0165r3 (C++ Standard Library Issues to be moved in Issaquah) with the exception of 2768 (which has been pulled back) and 2570, 2745, 2750, and 2733 (which apply to the LFTS)

Unanime

Motion 12: Response to US 81 and RU 4 Move to apply to the C++ working paper the proposed wording in P0426R1 (Constexpr for std::char_traits).

Unanime

Motion 13: Response to US 80 and FI 6 Move to apply to the C++ working paper the proposed wording in P0403R1 (Literal suffixes for basic_string_view).

Unanime

Motion 14: Response to GB 50 Move to apply to the C++ working paper the proposed wording in P0505R0 (Wording for GB 50 - constexpr for chrono).

Unanime. On est au point où <chrono> est totalement constexpr sauf pour now() et les conversions vers/de std::time_t

Motion 15: Response to CA 16 Move to apply to the C++ working paper the proposed wording in P0418R2 (Fail or succeed: there is no atomic lattice). This also resolves LWG issue 2445.

Unanime

Motion 16: Response to GB 58 Move to apply to the C++ working paper the proposed wording in P0508R0 (Wording for GB 58 - structured bindings for node_handles).

Unanime

Motion 17: Response to GB 68, US 155, US 154 Move to apply to the C++ working paper the proposed wording in P0503R0 (Correcting library usage of "literal type").

Unanime

Motion 18: Response to FI 19 Move to apply to the C++ working paper the proposed wording in P0414R2 (Merging shared_ptr changes from Library Fundamentals to C++17) and P0497R0 (Fixes to shared_ptr support for arrays).

Alisdair Meredith dit détester l'idée d'avoir deux interfaces pour un même concept mais accepter la décision, prise dans une réunion antérieure. On rit un peu

Unanime

Motion 19: Response to CH 3A Move to apply to the C++ working paper the proposed wording in P0504R0 (Revisiting in-place tag types for any/optional/variant).

Unanime

Motion 20: Response to US 18, US 70 and GB 43 Move to apply to the C++ working paper the proposed wording in P0003R5 (Removing Deprecated Exception Specifications from C++17).

Unanime

Motion 21: Response to US 112, US 115, US 116, US 117, US 120, US 181, FI 22, CH 3B, CH 4, CH 5, CH 6, and CH 8 Move to apply to the C++ working paper the proposed wording in P0510R0 (Disallowing references, incomplete types, arrays, and empty variants).

Unanime

Motion 22: Response to GB 62 Move to apply to the C++ working paper the proposed wording in P0516R0 (Clarify That shared_future’s Copy Operations have Wide Contracts).

Unanime

Motion 23: Response to GB 41 and GB 42 Move to apply to the C++ working paper the proposed wording in P0509R1 (Updating “Restrictions on exception handling”).

Unanime

Motion 24: Response to US 15, US 16, US 167, US 168, US 169, US 170, CA 17 Move to apply to the C++ working paper the proposed wording in P0502R0 (Throwing out of a parallel algorithm terminates—but how?).

Unanime

Motion 25: Response to US 163 Move to apply to the C++ working paper the proposed wording in P0517R0 (Make future_error Constructible).

Unanime

Motion 26: Response to CA 14 Move to apply to the C++ working paper the proposed wording in P0521R0 (shared_ptr use_count/unique).

Consensus

Motion 27: Response to FI 15, GB 69 Move to apply to the C++ working paper the proposed wording in P0513R0 (Poisoning the Hash). Also resolves LWG 2791 and LWG 2543.

Unanime

Motion 28: Response to FI 5 Move to apply to the C++ working paper the proposed wording in P0067R5 (Elementary string conversions, revision 5) - just the changes to the library clauses.

Unanime

Motion 29 Move to apply to the C++ working paper the proposed wording in P0435R1 (Resolving LWG Issues re common_type). Resolves LWG issues 2465 and 2763.

Marshall Clow indique que ça a été très difficile à écrire; il y a eu des travaux à Chicago lors d'une rencontre spéciale de LWG, encore du travail cette semaine, et il pense que c'est enfin correct.

Unanime

C'est pas mal. On a fini les votes vers 17 h 30, une heure plus tôt qu'à l'habitude!

Marshall Clow remercie les scribes de LWG. Nicolai Josuttis indique que ce fut pour lui l'une des rencontres les plus productives et les plus constructives des vingt dernières années. Tony van Eerd remercie Herb Sutter, notre hôte. Walter E. Brown remercie des tas de gens, incluant les membres de nos familles pour nous laisser faire ce travail. Et on ferme les livres sur la journée vers 17 h 35.

On est tous un peu cuits après ce marathon. Il reste bien sûr demain matin, et peut-être demain en début d"après-midi, mais pour le reste on a fait l"essentiel du travail, et ça s"est somme toute bien passé. J"ai fait des trucs mineurs sur mon doctorat, mais pas sur le texte (j"étais pas assez éveillé intellectuellement pour ça); j"ai plutôt faite une refactorisation qui réduira le temps de débogage en enlevant une couche que j"en suis venu à voir comme redondante (pour les curieuses et les curieux : j"avais une couche NVI pour une interface qui était aussi, en pratique, utilisée dans un contexte NVI, ce qui ajoutait des étapes à chaque test quand je traçais le code; ça devrait tous nous rendre un peu plus productifs). Puis je suis allé dormir au son de la voix de Leonard Cohen.

Jour 5 12 novembre 2016

Dernier matin ici. J"ai écrit un petit mot à mon amoureuse Za, fait mes bagages, pris ma douche, passé un rasoir sur mon visage qui se transforme en cactus après un jour ou deux, mais surtout qui s"assèche quand la barbe pousse (et on boit beaucoup, beaucoup de café ici alors il faut faire attention).

J'ai déposé mes bagages au lobby (pour ne pas les traîner toute la journée), fait mon « check-out » et j'ai pris des dispositions pour le trajet vers l'aéroport (semble qu'un Town Car soit plus rapide et moins coûteux qu'un taxi). Déjeuner de saucisses, oeufs cuits durs et muesli. La dame qui a desservi notre salle de travail toute la semaine est gentiment venue nous souhaiter une bonne fin de séjour et un bon voyage de retour.

Ma journée a débuté par une présentation devant SG1 :

Plusieurs échanges ont eu lieu.

Quelques constats découlent du processus décisionnel :

Un des membres de SG1 a exprimé la suggestion que thread::native_attributes pourrait être préférable à thread::attributes pour nommer le concept exprimé ici, dans un souci de cohésion avec thread::native_handle. C'est une question à explorer.

Ma compréhension est qu'il faudra trois propositions pour répondre aux positions de SG1, soit :

Un qui explorera la question de l'adoption d'un native handle sur un thread existant par un std::thread. Ceci demandera (à l'oeil) au moins deux itérations devant SG1

Un qui explorera l'utilisation de thread::attributes (peu importe leur nom) dans le contexte d'une fonction de fabrication, et

Un qui explorera une API pour s'enquérir des propriétés d'un std::thread, à partir de son id ou de son native_handle

Je reviens à CWG où on établit la priorité des Issues à traiter lors de la prochaine rencontre. J'en ai bien sûr manqué quelques-unes.

Core issue 2192: Constant expressions and order-of-eval undefined behavior

Ceci devrait-il compiler?

constexpr int f() {
   int x = 2;
   return ++x * ++x; //should return 12
}
constexpr int x = f();
static_assert(x==12,"shouldn't work");
int main(){}

Suite à la proposition de Gabriel Dos Reis sur l'ordonnancement des expressions, ceci pose encore problème car certains des opérandes ne sont pas ordonnancés. Clark Nelson : les gens souhaitent « indeterminately sequenced », pas « unsequenced ». Priority 2.

Core issue 2193: numeric_limits<int>::radix and digits

Selon le texte du standard, il n'est pas clair si numeric_limits<int>::radix == 2 doit s'avérer. NAD.

Core issue 2194: Impossible case in list initialization

On va simplement enlever le cas offensant. Roger Orr s'en occupe.

Core issue 2195: Unsolicited reading of trailing volatile members

Priorité 2. Le correctif sera intégré à celui pour CH2.

2196. Zero-initialization with virtual base classes

Avec ce code :

struct V { int n; };
struct A : virtual V {};
struct B : A {
  B() : V{123}, A() {}
} b;

... b.n devrait valoir zéro. Richard Smith dit que Hubert Tong voudra clarifier l'initialisation (ou non) du padding dans le parent virtuel.

2197. Overload resolution and deleted special member functions

Cet Issue est d'ordre terminologique. Éditorial.

2198. Linkage of enumerators

Les règles dans [basic.link] disent que les énumérateurs ont un linkage, ce qui rend ce programme malformé :

//tu1.cpp:
enum E1 { E };
int f() { return E; }
// tu2.cpp:
enum E2 { E };
int f();
int main() { return f(); }

John Spicer fait remarquer que ça provoque une violation d'ODR que les programmeuses et les programmeurs ne peuvent pas savoir qu'elles ou qu'ils commettent. Jens Maurer s'en occupe.

2199. Typedefs and tags

Il y a variation du comportement selon les implémentations dans les interactions entre les typedef et les elaborated-type-specifiers, du moins dans certains cas. Par exemple :

namespace A {
  struct S {};
}
namespace B {
  typedef int S;
}
namespace C {
  using namespace A;
  using namespace B;
  struct S s; // clearly ambiguous, S names different entities
}
namespace D {
  using A::S;
  typedef struct S S;
  struct S s; // OK under DR407: S could be used in an elaborated-type-specifier before the typedef, so still can be
}
namespace E {
  typedef A::S S;
  using A::S;
  struct S s; // ??? the identifier S could not have been used in an elaborated-type-specifier prior to the typedef, so is this lookup ill-formed because it finds a typedef-name?
}
namespace F {
  typedef A::S S;
}
namespace G {
  using namespace A;
  using namespace F;
  struct S s; // ??? F::S could not have been used as an elaborated-type-specifier before the typedef. is this ill-formed because the lookup finds a typedef-name?
}
namespace H {
  using namespace F;
  using namespace A;
  struct S s; // some implementations give different answers for G and H
}

Les règles implémentées dans Clang sont, dans les mots de Richard Smith :

Ça semble pas mal. Reste à clarifier le texte du standard. Priorité 0.

2200. Conversions in template argument deduction

Étant donné ceci :

struct S {
  operator int();
};
template<int N>
   void f(const int (&)[N]);
int main() {
  S s;
  f<2>({s, s}); // #1
  f({s, s});    // #2
}

...puisque la déduction du tableau échoue, pourquoi ne pas considérer la conversion implicite vers un int? Mais on convient que les règles existantes ont le mérite d'être plus simple. Jens Maurer demande si on peut déduire N de la notation entre accolades; Richard Smith dit à quel endroit. John Spicer suggère qu'on ne touche pas à cela. Hubert Tong aussi. NAD et si quelqu'un veut le changer, une proposition sera accueillie.

2201. Cv-qualification of array types

Problème surtout terminologique. Priorité 0. Mike Miller le rédigera.

2202. When does default argument instantiation occur?

Étant donné ceci :

#include <type_traits>
template<class T> struct Foo {
  Foo(T = nullptr) {}
};
bool b = std::is_constructible<Foo<int>>::value;
int main() {}

Clang and EDG rejettent ceci, car is_constructible triggers provoque une instantiation du paramètre, ce qui entraîne une erreur hors du contexte immédiat du test, alors que g++ l'accepte, mais a l'effet somme toute surprenant que is_constructible<Foo<int>>::value==true, ceci bien que si on cherche à construire un Foo<int> par défaut cela échouera. MSVC rejette ceci en instanciant Foo<int> qu'il y ait une tentative de construction ou non. Quelle est la bonne réponse?

Il y a des débats ici, c'est intéressant. Les tenants de la « position g++ » la trouvent plus conviviale; les tenants de la « position Clang » estiment que c'est trop demander au compilateur. On s'entend pour une priorité 1. Hubert Tong pense qu'il faudra informer LWG du problème avec certains traits et leur « implémentabilité ».

2203. Defaulted copy/move constructors and UDCs

Soit ceci :

struct A {
    A();
    A(A&);
    explicit A(int);
    operator int() const;
};
struct B {
    B(B&& other);
    A a;
};
B::B(B&& other) : a(static_cast<B&&>(other).a) {}
//B::B(B&& other) = default; // ill-formed
void f(B& b1) {
    B b2 - static_cast<B&&>(b1);
}

Le constructeur de mouvement « maison » est bien formé car B::a peut être initialisé par A::operator int() et A::A(int). Toutefois, Clang et g++ estiment qu'une version =default serait malformée. Richard Smith a l'impression qu'on parle d'un bogue dans Clang, où on utiliserait la mauvaise clause d'initialisation dans ce cas.

Jason Merrill pense que ça a un lien avec Core Issue 1092. C'est une tactique de contournement pour un autre problème. Il va écrire quelque chose.

On prend une pause vers 10 h 18. J'informe Vicente J. Botet Escribá, Arthur O'Dwyer et Billy Baker de ma compréhension de la position de SG1 (voir plus haut).

Richard Smith veut parler de §3.8p8 en lien avec std::launder(). L'exemple de référence serait :

struct A { int a; int b; };
struct B { float a; int b; };
void f() {
  A *p = new A{1, 2};
  int &r = p->b;
  new (p) B {3.0, 4};
  assert(r == 4);
}

Il y a un bogue dans le modèle objet du langage, qui nous force à passer par std::launder() même pour les membres non-const, ce qui est un peu abusif. On ouvre un Core Issue pour ça.

On escamote 2204, qui repose sur un malendendu.

2205. Restrictions on use of alignas

On a un exemple qui dit que ceci :

alignas(double) void f();

... est illégal, mais le texte normatif ne supporte pas l'exemple. Richard Smith a une proposition de terminologie pour corriger cela. On rend le tout Ready.

2206. Composite type of object and function pointers

Soit cet exemple :

void *p;
void (*pf)();
auto x = true ? p : pf;

Les règles de §5p13 [expr] indiquent qu'un type composite entre void* et un type de pointeur de fonction est void*, ce qui surprend car un pointeur de fonction ne peut pas implicitement être converti en void*. Jens Maurer va écrire le correctif.

2207. Alignment of allocation function return value

Les contraintes sur l'alignement des adresses retournées par les fonctions d'allocation semblent trop strictes. On discute sur la pratique existante. Roger Orr va écrire quelque chose.

2211. Hiding by lambda captures and parameters

Qu'imprimera ceci?

#include <iostream>
int main() {
  [x=2](int x) { std::cout << x << std::endl; }(3);
}

Davis Herring pense qu'on devrait marquer ceci comme ill-formed. Richard Smith pense que c'est déjà ill-formed, sur la base de §3.3.2p4 :

« Given a set of declarations in a single declarative region, each of which specifies the same unqualified name, [...] they shall all refer to the same entity [or a case that doesn't apply here] »

Hubert Tong voit un cas d'utilisation pour cela. On échange, et on tranche pour ill-formed. Jens Maurer va clarifier le tout.

2212. Typedef changing linkage after use

Oh boy. L'exemple motivateur est :

typedef struct { void f() { extern decltype(*this) x; void *p = &x } } x;

Jens Maurer pense que ill-formed est le chemin à suivre. Richard Smith mentionne qu'il existe plusieurs cas monstrueux comme celui-ci alors il ne faut pas l'approcher par un traitement de cas particulier. Richard Smith a des suggestions terminologiques mais on trouve qu'ils brisent trop de code. On examine des manières de le faire fonctionner plutôt que de l'interdire. John Spicer fait remarquer qu'on aurait pu construire d'autres types sur la base de decltype(*this) alors c'est difficile d'empêcher cela. Daveed Vandevoorde suggère un lookahead jusqu'à la fin de la déclaration (ça peut nous amener loin, par contre). On regarde et il faut déjà le faire. Il y a un exemple dans §7.1.3p9 qui nous lie un peu (c'est un truc qui a une trentaine d'années) :

typedef struct { } *ps, S; // S is the class name for linkage purposes

Richard Smith suggère de rendre ceci implementation-defined, mais c'est pas gentil. Hubert Tong blague ill-formed, no diagnostic required. Richard Smith lance l'idée de unspecified. On indique p3. Daveed Vandevoorde pense que ça mérite une proposition.

2213. Forward declaration of partial specializations

On ne les permet pas, mais il ne semble pas y avoir de bonne raison pour cela. On va le permettre. Richard Smith a une proposition terminologique pour celle-là. On a quelques exemples à examiner :

namespace N {
  struct A;
  template<typename T> struct B {};
}
template<typename T> struct C {};
struct D {
  template<typename T> struct A {};
};
struct N::A; // #1

template<typename T> struct N::B; // #1
template<typename T> struct N::B<T*>; // #2
template<> struct N::B<int>;
template struct N::B<float>;

template<typename T> struct C;
template<typename T> struct C<T*>; // #2
template<> struct C<int>;
template struct C<float>;

template<typename T> struct D::A; // #1
template<typename T> struct D::A<T*>; // #2
template<> struct D::A<int>;
template struct D::A<float>;

En gros, Richard Smith pense que les lignes #1 et #2 sont ill-formed, mais que l'intention est de rendre les #1 ill-formed et les #2 valides. Il y a toutefois des petites nuances. On discute encore et ils deviendront probablement tous valides sauf pour les tout-derniers. Jens Maurer pense que ça mérite de la terminologie écrite avec soin. John Spicer va le faire.

2214. Missing requirement on representation of integer values

Dans §3.9.1p3 [basic.fundamental], on indique :

« The range of non-negative values of a signed integer type is a subrange of the corresponding unsigned integer type, and the value representation of each corresponding signed/unsigned type shall be the same. »

Dans C11, on trouve plutôt :

« The range of nonnegative values of a signed integer type is a subrange of the corresponding unsigned integer type, and the representation of the same value in each type is the same. »

La terminologie C semble plus claire, mais perd l'intention de C++ à l'effet que le bit d'un type signé fait partie de la représentation des valeurs du type non-signé correspondant. Priorité 0. Jens Maurer le prendra.

2215. Redundant description of language linkage in function call

C'est un bogue terminologique; le standard se contredit dans certains cas.

2216. Exception specifications in unevaluated contexts

Soit cet exemple :

#include <type_traits>
template<class T>
T foo(T) noexcept(std::is_nothrow_move_constructible<T>::value);
int main() {
  sizeof(foo(0));
}

Selon §15.4 p19 :

« An exception-specification is considered to be needed when: (19.1) in an expression, the function is the unique lookup result or the selected member of a set of overloaded functions [...] »

Mais il se trouve que :

sizeof(foo(0))

...est une expression et que, dans cette expression, on trouve un contexte de fonction foo<int>() non-évalué. Il faudra soit le rendre ill-formed, soit raffiner notre terminologie pour les spécifications d'exceptions. Pour le moment, on s'en tient à NAD.

2217. constexpr constructors for non-literal types

La question soulevée est de savoir si ceci est légal :

struct S {
  constexpr S(): i(42) {  }
  ~S();
  int i;
};
double x[S().i]; // Error

Le constructeur est inutile dans ce cas. On convient d'un NAD.

2218. Ambiguity and namespace aliases

Les implémentations divergent sur ceci :

namespace A { namespace B { int x; } }
namespace C { namespace B = A::B; }
using namespace A;
using namespace C;
int x = B::x;

... mais pas sur cela :

namespace A { struct B { static int x; }; }
namespace C { using A::B; }
using namespace A;
using namespace C;
int x = B::x;

Richard Smith propose une terminologie pour résoudre ce cas et clarifier le comportement attendu des implémentations. Ça convient. Ready.

Mike Miller nous invite à revenir après la plénière pour une séance de travail informelle en attendant de devoir quitter pour prendre nos avions respectifs.

On arrête vers 12 h. Le repas est fait de quesadillas (portobello ou porc, selon les préférences), fèves noires, riz espagnol, salade de choux et croustilles de maïs chaudes. C'est bon mais bourrant. Les tractations politiques se poursuivent dans plusieurs directions mais ne se racontent pas ici.

La plénière débute vers 13 h 10. Certains se plaignent que l'agenda indiquait 13 h 30. Je pense qu'ils ont raison, mais bon, la majorité semble être à l'aise avec le changement. Faut dire que presque tout le monde est là.

Clark Nelson valide que personne ne souhaite renverser une décision prise hier. Personne ne prend une telle position, alors les votes d'hier sont acceptées en bloc.

Herb Sutter indique qu'après Kona en février et Toronto en juilet, la rencontre suivante débutera le 6 novembre 2017 à Albuquerque, Nouveau-Mexique.

Pour les publications post-Issaquah, l'échéance est le 28 novembre 2016, 18:00 UTC. Pour pré-Kona, ce sera le 6 février 2017.

Mike Miller pense que CWG tiendra entre trois et quatre téléconférences avant Kona pour réduire la quantité de Issues à traiter pour C++ 17. Marshall Clow envisage deux téléconférences pour LWG. Michael Wong envisage des téléconférences mensuelles pour SG14.

Marshall Clow et Mike Miller indiquent tous deux que leurs groupes respectifs se réunissent encore après la plénière pour poursuivre les travaux tant qu'il reste des forces fraîches.


On se retrouve chez CWG pour poursuivre les travaux pendant que c'est possible.

2219. Dynamically-unreachable handlers

Dans l'exemple suivant, il y a un gestionnaire d'exception mais il n'est pas atteignable en pratique :

#include <cstdio>
#include <cstdlib>
void f() {
  struct X {
    ~X() {
      std::puts("unwound");
      std::exit(0);
    }
  } x;
  throw 0;
}
int main(int argc, char**) {
  try {
    f();
  } catch (int) {
    std::puts("caught");
  }
}

Devrait-on appeler std::terminate()? On convient d'en faire une priorité 1.

2220. Hiding index variable in range-based for

On se demande quoi faire avec ceci :

void f() {
  int arr[] = { 1, 2, 3 };
  for (int val : arr) {
    int val;   // Redeclares index variable
  }
}

Jens Maurer s'en occupe

2221. Copying volatile objects

Le code suivant semble malformé en vertu des règles en vigueur, parce que const volatile& n'est pas une signature assujettie à =default :

struct S {
  int i;
  S(const S&) = default;
  S(const volatile S&) = default; // ill-formed
};
volatile S s1;
S s2(s1);

Changement éditorial. Le texte pourrait être plus clair.

2224. Member subobjects and base-class casts

Quelqu'un semble penser que ceci est légal selon le texte du standard, alors que ça ne semble pas être un exemple raisonnable :

struct B {
  int i;
};
struct D : B {
  int j;
  B b;
};
int main() {
  D d;
  B &br = d.b;
  D &dr = static_cast<D&>(br); // p2 suggests that dr should refer to d?
}

On changera une note en texte normatif pour éviter la confusion. Roger Orr s'en occupera.

2225. reinterpret_cast to same floating-point type

L'auteur de celle-ci nous souligne un cas difficile à expliquer :

void func(long l, float f) {
  (void)reinterpret_cast<long *>(&); // ok
  (void)reinterpret_cast<long>(l); // ok
  (void)reinterpret_cast<float *>(&f); // ok
  (void)reinterpret_cast<float>(f); // ill-formed
}

Richard Smith mentionne qu'on ne le permet pour aucun type à virgule flottante. Laisser ça passer ouvre une boîte de Pandore. NAD.

2226. Xvalues vs lvalues in conditional expressions

Oh boy... Quel est le type de cette expression?

const T a;
T b;
false ? a : std::move(b); // <--

On serait tentés de penser const T mais le texte du standard n'est pas limpide en ce sens. Jens Maurer s'en charge.

2227. Destructor access and default member initializers

On se demande quoi faire avec ceci (remarquez qu'il s'agit d'un agrégat et d'un aggregate-initializer) :

class X { ~X(); }; // destructeur privé
struct Y { X x = {}; }; // implicite
// et ceci?
auto *y = new Y{};

Jens Maurer pense que Y ne peut être construit car un de ses attributs ne peut être construit. Il y a divergence entre les implémentations. On cherche ce que le standard dit. Le piège ici est qu'il n'y a pas de constructeur car on parle d'aggregate-initialization. Faudra clarifier le propos ici. Jens Maurer s'en occupe.

2228. Ambiguity resolution for cast to function type

Soit le code suivant :

int x = (int()) + 5;

Ceci est malformé dû à [dcl.ambig.res]/2 qui dit de traiter int() comme un type-id, pas comme un transtypage : ceci constitue un transtypage en un type de fonction. Cela semble suspect, car le choix dicté par le standard est inutile. En plus, la plupart des implémentation gèrent mal ce cas (ici, EDG et g++ rejettent ce code, qui est valide, Clang le compile incorrectement) :

struct T { int operator++(int); T operator[](int); };
int a = (T()[3])++; // not a cast

Faut trouver une écriture qui soit meilleure mais évite des horreurs comme (int(*)()). Daveed Vandevoorde suggère un truc comme « a cast to a function type or an array of function types is not a cast ». Richard Smith pense qu'il faut s'en occuper, car des gens frappent ce cas à l'occasion, et suggère un priorité 0. Il s'en occupera (il y a dissension sur ce sujet).

2229. Volatile unnamed bit-fields

On n'a pas la description, mais le titre fait crouler la salle de rire.

2230. Linkage of extern "C" function in unnamed namespace

Ceci pose problème :

namespace { extern "C" void f() { } } 

Est-ce external linkage ou internal linkage? Richard Smith pense que c'est un NAD.

2231. Class member access to static data member template

On nous rapporte que ceci ne compile pas, mais que la raison n'est pas évidente :

struct A {
  template<class T> static int X;
};
template<class T> int A::X = T{};
A{}.X<int>; // Not OK
A::X<int>; // OK 

Mike Miller indique NAD. C'est un bogue de compilateur.

2232. thread_local anonymous unions

On n'a pas la description de celle-là, mais c'est un autre cas dont le titre est divertissant.

2233. Function parameter packs following default arguments

Une proposition cherche à rendre ceci valide :

template<typename ...T> void f(int n = 0, T ...t); 

... mais un truc comme ceci poserait encore problème :

void f<int>(int n = 0, int); 

... (en le testant avec f<int>() sans paramètre, les compilateurs souffrent; en particulier, g++ fait un SEGFAULT; Jason Merrill fait semblant de s'endormir et on se bidonne). Jason Merrill suggère qu'on écrive un truc comme « essayer d'utiliser un paramètre avec une valeur par défau quand celui n'est pas là constitue une erreur ». Priorité 0. Jens Maurer l'écrira.

2234. Missing rules for simple-template-id as class-name

Techniquement, ceci est malformé, mais pourquoi? Le standard n'est pas limpide sur ce point :

template<typename T> struct X;
struct X<int> {
}; 

Jens Maurer a une proposition de formulation et le prend en charge.

2235. Partial ordering and non-dependent types

Sois cet exemple de §14.8.2.5/11 

template <class T> T f(int); // #1
template <class T, class U> T f(U); // #2
void g() {
  f<int>(1); // calls #1
}

Sur la base du paragraphe 4, qui dit « If a particular P contains no template-parameters that participate in template argument deduction, that P is not used to determine the ordering », il faut ignorer le cas P=int, A=U, et faire en sorte que la déduction réussisse pour le cas P=U, A=int de telle sorte que les deux templates soient aussi spécialisés l'un que l'autre.

Pour un autre exemple :

template <class... T> struct V {};
template <class... Ts, class... Us> void Foo(V<Ts...>, V<Us&...>) {} // #3
template <class... Us> void Foo(V<>, V<Us&...>) {} // #4
void h() {
  Foo(V<>(), V<>());
}

Hubert Tong pense que le problème de fond est que nous de traitons pas l'ordonnancement partiel de la bonne manière. Richard Smith pense que c'est un NAD. Jens Maurer va écrire quelque chose.

En fouillant, on est tombés sur §14.8.2.5p8 qui est une immonde formule illisble... Faudra réouvrir Core Issue 1847 pour couvrir celle-là : en comparant les types de retour, on voit deux noms de types qui semblent correspondre mais sont distincts, et on fera notre possible. On converge vers NAD avec justification. On parle d'une heure de discussion ici; je ne rend pas justice à ce qui a été dit.

On prend une pause de cinq minutes mais je me limite à de l'eau.

2236. When is an alias template specialization dependent?

Il y a divergence sur le besoin ou pas du mot clé typename dans l'exemple suivant :

struct A { typedef int type; };
template <typename T> using ALIAS=A;
template <typename T> void foo() {
     ALIAS<T>::type t; // is typename required here?
}
int main() {
   foo<A>();
} 

On va ajouter une note non-normative.

2237. Can a template-id name a constructor?

Quelqu'un nous fait remarquer que §12.1/1 [class.ctor] puce 1.2 pemet un template-id dans certains cas de constructeurs, dont ce truc suspect :

template<class T> struct X {
  X<T>(T); // constructor
};

Heureusement, ceci semble illégal :

template<class T> X<T>::X<T>(T); 

John Spicer pense qu'il faut une annexe ou un truc du genre, car c'est une régression. David Herring fait remarquer que la règle existante permet des trucs qui ne font pas de sens, ce qui l'horripile. Jens Maurer s'en occupe. Richard Smith fait remarquer qu'il est important de réserver cette syntaxe pour les spécialisations.

2238. Contradictory alignment requirements for allocation

Le discours sur l'alignement des objets est contradictoire dans §3.7.4.1 et §18.6.1. Faut les harmoniser. Richard Smith soulève la question des types sur-alignés.

2239. Sized deallocation with a trivial destructor

Le texte de §5.3.5p10 [expr.delete] dit que « deletion of an array of a class with both sized and non-sized deallocation functions is not required to call the sized version if the destructor is trivial » :

« If deallocation function lookup finds both a usual deallocation function with only a pointer parameter and a usual deallocation function with both a pointer parameter and a size parameter, the function to be called is selected as follows:

Par contre, si on ne spécifie qu'une version avec taille en tant que class-specific deallocation function, et si la classe a un destructeur trivial, il n'est pas clair comment évaluer la taille à passer au destructeur. Richard Smith pense que ça recoupe la question du point précédent.

2240. this is not odr-used in a constant expression

David Herring pense que ça a été traité à Jacksonville.

2241. Overload resolution is not invoked with a single function

Richard Smith essaie de relater ce qui, dans son souvenir, est ce problème, car nous n'avons pas accès au texte.

2242. ODR violation with constant initialization possibly omitted

Ceci, selon Hubert Tong, devrait être une violation d'ODR, alors que Richard Smith pense que ce n'est pas le cas :

// tu1.cpp
extern const int a = 1;
inline auto f() {
  static const int b = a;
  struct A { auto operator()() { return &b; } } a;
  return a;
}
// tu2.cpp
extern const int a;
inline auto f() {
  static const int b = a;
  struct A { auto operator()() { return &b; } } a;
  return a;
}
int main() {
  return *decltype(f())()(); // ouch
}

À réfléchir...

On ferme vers 16 h. Je bavarde un peu avec Jens Maurer et Hubert Tong avant d'embarquer dans le Town Car qui m'attendait. J'y ai eu un excellent service, mais ne vous faites pas prendre, c'était (un peu) plus cher que le taxi. On me l'avait fait venir tôt sous prétexte que le trafic serait horrible, mais bon, nous sommes samedi et il y a un match de football collégial alors ça nous a pris moins de temps qu'à l'habitude et j'étais à l'aéroport plus tôt que prévu.

Passage aux douanes, nouvelle politique où il faut placer nos souliers hors des bacs de plastique (hé la la...). Je croise Billy Baker avec qui je bavarde un peu (il y a déjà des mini scandales politiques et la réunion n'est terminée que depuis une heure environ), puis je me trouve un endroit pour travailler (les stations de travail prévues à cet effet n'ont pas d'alimentation électrique, aucune idée pourquoi). Pour le reste, c'est un voyage tranquille, avec des épisodes de sommeil cours et épars, qui se termine avec le visage de mes plus jeunes et de ma belle qui viennent me cueillir à l'aéroport. Une belle fin à une dizaine de jours un peu déments.

Glossaire

Plusieurs 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

NB

National Body

Pays participant au processus de standardisation

CD

Committee Draft

Le premier jet du standard, qui sera soumis aux pays pour leur donner une opportunité de se prononcer sur le contenu et de soumettre des demandes de correctifs

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

DIS

Draft International Standard

Étape intermédiaire entre le CD, suivant les NB Comments, et le IS.

DR

Defect Report

Document rapportant une défectuosité dans le texte du standard, et mettant typiquement de l'avant une possible solution à l'attention du comité

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

NB Comments

National Body Comments

Une fois un CD livré, celui-ci est examiné par les pays participant au processus de standardisation. Ceux-ci livrent, en tant que pays, des commentaires pour améliorer le CD avant qu'il de devienne un DIS, puis un IS.

PDTS

Pre DTS

Un pré-DTS 

QoI

Quality of Implementation

Aspect laissé à la discrétion des vendeurs, qui dépend de la qualité de leur implémentation (p. ex. : la nature des messages diagnostics produits)

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. Les groupes d'étude existants sont :

  • SG1 : Concurrency and Parallelism
  • SG2 : Modules
  • SG3 : File System
  • SG4 : Networking
  • SG5 : Transactional Memory
  • SG6 : Numerics
  • SG7 : Reflection
  • SG8 : Concepts
  • SG9 : Ranges
  • SG10 : Feature Test
  • SG12 : Undefined and Unspecified Behavior
  • SG13 : I/O
  • SG14 : Low Latency

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

WD

Working Draft

Littéralement : un document (formel) de travail

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 !