À propos de WG21, Kona 2019

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 conduct (I really don't want to do that!), 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) as it might interest my students to see what kind of argument these bright individuals can formulate. Should you think it would be appropriate for me to remove things from this page, please tell me and I will proceed switfly.

Based on a clarification of the ISO code of conduct, I have anonymized all in-meeting discussions except for self-evident things like chairs asking for votes.

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. Sans le soutien de Yasmine Lee, aussi du CeFTI, ma vie serait singulièrement plus compliquée.

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 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 quelques années plus tard (C++ 14), et la première mise à jour majeure à laquelle j'ai activement participé, C++ 17, a été votée à la rencontre de Kona 2017.

Nous travaillerons à WG21 pour les prochaines années sur C++ 20, de même que (pour la présente rencontre) sur des correctifs idéalement mineurs à C++ 17. Les objectifs de C++ 20 sont très ambitieux, et font saliver les gens qui, comme moi, cherchent à tirer le maximum de ce que ce langage a à offrir. Certains des éléments les plus importants que nous souhaitions voir intégrés au langage à partie de C++ 17 ont dû être retardés pour diverses raisons, et nous souhaitons les voir faire partie d'un  C++ 20 de grande envergure.

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 150.

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). Dans le respect des règles de procédure en vigueur, le nominatif lors des échanges techniques aura été supprimé de la version à laquelle vous aurez accès.

Fin du contenu technique

Au préalable

Le standard du langage C++, depuis son importante révision de 2011, évolue à un rythme accéléré (le Train Model est le terme généralement utilisé pour décrire ceci : on s'impose des mises à jour régulières). Nous avons procédé à une mise à jour « mineure » (quoique...) en 2014, une importante (mais dans laquelle certains « gros morceaux » attendus n'ont pas été intégrés) en 2017, et nous planifions donner un coup de barre majeur en 2020 avec C++ 20. Cette mise à jour comprendra, dans un monde idéal :

La rencontre de cette semaine vise à fixer ce qui fera effectivement partie de C++ 20. C'est une rencontre très importante.

Jour -1 16 et 17 février 2019

Ce fut un début de voyage mouvementé. En partie par ma faute, et en partie dû à des circonstances hors de mon contrôle. Heureusement, ma belle Za m'a sauvé d'un mauvais pas, et je pourrai avoir une semaine frugale mais productive. Za... Une chance que je t'ai! Et je te dois une fière chandelle.

Tout d'abord, pourquoi le jour -1 est-il en fait deux jours (les 16 et 17 février)? Parce que je me suis levé samedi le 16 vers sept heures du matin, et que je ne me suis pas encore couché au moment d'écrire ces lignes (nous sommes le 17 et il est 15 h à Hawaï, 20 h à Montréal). Ma journée a commencé par de la routine (cours de karaté avec mon plus jeune Ludo, faire à manger, sortir les ordures, amener ma grande Vayda à son cours de danse, saluer mon ainée Marguerite au passage, etc.)... et des bagages, pour lesquels Za a eu la gentillesse de m'aider (elle s'amuse avec les techniques de pliage de Marie Kondo ces temps-ci, et je dois lui accorder que ça épargne beaucoup d'espace). Mon chic papa Réal a eu la gentillesse de m'amener à l'aéroport, libérant Za pour la gestion du transport des enfants (normalement, on se sépare les tâches, mais quand je pars, elle a les mains pleines!).

Le départ de Montréal s'est fait sans anicroches. Seul truc nouveau (pour moi) et qui m'a fait sourire : il y a maintenant un dépôt pour se débarrasser des produits du cannabis (je n'en prends pas, si vous êtes curieuses ou curieux, mais ça m'a fait sourire quand même) avant de franchir les douanes.

Mon voyage vers Hawaï comportait deux étapes : Montréal vers Los Angeles, puis Los Angeles vers Kona. Le hic, c'est que pour des raisons financières, j'avais choisi un trajet avec une attente de douze heures (de 20 h 30 àh 30 environ) à Los Angeles. Ça fait un trajet un peu long (surtout que le Wi-Fi de LAX n'est vraiment pas terrible... et que même le plus humble café y coûte une fortune!)

En attendant mon avion à Montréal, j'ai fait un peu de correction (certain(e)s de mes étudiant(e)s m'ont envoyé des messages indiquant qu'elles / ils avaient bien hâte d'avoir une rétroaction sur certains travaux, et elles / ils ont bien raison!).

Mon trajet de Montréal vers Los Angeles s'est fait sur un avion très moderne, très propre, avec des écrans sophistiqués et tout le tralala. J'avais le siège côté hublot, et ma voisine immédiate était une jeune enseignante de l'État de New York (mais plus près de Montréal que de New York City), qui frottait tout autour d'elle avec des lingettes pour bébé (pour désinfecter). Très sympathique cela dit. On a bavardé un peu, mais j'avais un peu la tête au travail alors qu'elle partait voir une amie pour une semaine de vacances. Le siège côté corridor est resté libre jusqu'à la dernière minute, quand est arrivé un beau grand jeune homme, enthousiaste et originaire de Chicago (mais qui habite maintenant à Los Angeles). Je les ai regardé aller, et je pense que j'ai vu un couple se former; ils ont parlé durant les six heures du trajet, et sont partis souper ensemble quand nous sommes arrivés à destination  . J'ai profité du trajet pour écrire des notes de cours, écouter quelques balados (dont CppCast, toujours excellent) et regarder Doctor Strange (Marguerite serait fière de moi!), et je me suis permis de manger un wrap au poulet (avec un verre de rouge, ça coûtait 12,00 CAD, ce qui est moins cher qu'à l'aéroport).

L'entre-deux un peu long a été utilisé pour régler quelques problèmes sur mon code de doctorat lorsque porté sur de nouvelles plateformes. Ces problèmes m'ont été signalés par Victor Ponce, un collègue à qui je dois beaucoup et qui a contribué à mon succès en utilisant mes travaux pour construire les siens. Un des trucs a demandé beaucoup de travail (rien de difficile, quoique... mais fallait de la rigueur et du doigté), et je ne l'ai fini que sur mon trajet entre Los Angeles et Kona. Versh du matin, j'étais un peu étourdi et j'étais un peu moins efficace, mais une fois les douanes passées, la petite marche m'a un peu réveillée. J'ai jonglé avec l'idée de manger quelque chose, mais un tout petit wrap déjeuner qui ne semblait pas terrible coutait 14,00 USD alors je me suis limité à un café (3,50 USD, c'est déjà beaucoup à mes yeux).

L'avion vers Kona était beaucoup moins moderne, et il n'y avait pas de service de divertissement (en fait, il y a une application pour tablettes et cellulaires pour qui souhaite payer). Ce fut un trajet tranquille, j'étais côté corridor avec des voisins sympathiques (un couple dans la quarantaine), qui m'a permis de travailler (surtout sur les problèmes soulevés par Victor Ponce) et de fermer les yeux, sans vraiment dormir. Je me suis permis d'écouter La soirée est encore jeune en balado (ça me fait vraiment beaucoup rire!). Le plus gros événement du trajet... fut que la jeune ado sur le siège juste en avant de moi a vomi tout ce qu'elle avait dans l'estomac... Heureusement, elle a (tout juste!) manqué mes souliers et le sac de mon ordinateur portatif. Ça sentait comme vous pouvez l'imaginer, et il restait encore trois heures de vol, mais son papa s'est chargé de nettoyer rapidement (les agents de bord étaient en train de servir nourriture et boissons à l'autre extrémité de l'appareil).

L'atterrissage à Kona fut rude. L'avion a brassé pas mal, mais nous sommes arrivés sains et saufs. Il faut chaud ici, un solide 25 °C mais pas particulièrement humide. J'ai remarqué que c'est la première fois (en trois voyages ici) que j'arrive en après-midi, mes autres séjours ayant tous débuté tard la nuit. Ça fait très différent : l'aéroport est plein de gens, qui arrivent ou qui attendent d'autres gens (il y a un Spring Break aux États-Unis cette semaine, apparemment). J'ai pris un taxi (36,00 USD, dans les normes) jusqu'à mon hôtel, le King Kamehameha Kona Beach Hotel. Chauffeur de taxi très peu bavard; sur la route, beaucoup de rochers volcaniques refroidis (spectaculaire!); j'aurais bien pris des photos mais j'étai assis à l'arrière et les fenêtres étaient fumées.

Je veux être clair : rien de tout cela n'est pas faute de mon employeur, qui m'a offert un excellent support. Je suis mécontent de ma banque, c'est tout; le reste est un concours de circonstances.

Arrivé à l'hôtel, j'ai eu un excellent accueil, et j'ai croisé plusieurs collègues qui arrivaient ou passaient par le lobby tout simplement (j'ai eu droit à des poignées de mains sincères pour la fin de mon doctorat; ça se prend bien!). Cest là que c'est devenu compliqué pour moi. Je savais que je serais « serré » pour payer le séjour, et j'avais planifié y arriver avec les sous venant d'une formation en entreprise que j'ai donnée récemment, mais elle n'a pas encore été payée, situation un peu embêtante quand on est près de ses sous comme moi (mais la faute de personne, j'insiste). On m'avait rappelé dernièrement l'existence de sources de financement alternatives, j'ai eu beaucoup de soutien de ce côté, mais les sous qu'on m'a accordés ne sont pas encore arrivés là non-plus (c'est la faute de personne ici non plus). C'est bête car il ne me manquait pas beaucoup. Voyant venir le coup, j'avais appelé ma banque plus tôt cette semaine pour prendre un arrangement temporaire (en gros : élever temporairement mon crédit pour quelques jours, un truc que j'ai déjà fait il y a quelques années dans une situation semblable); la personne au bout du fil du côté de la banque vendredi m'avait dit de ne pas m'en faire, d'aller à Kona et de les appeler si jamais je constatais qu'il manquait bel et bien un peu de sous (c'est une question de taux de change; j'aurais pu être Ok ou pas, mais c'était serré). Malheureusement pour moi, quand j'ai appelé la banque à partir de Kona, comme entendu, celle-ci n'a pas tenu sa parole et m'a dit, gentiment mais fermement, de m'arranger avec mes problèmes. Je m'occuperai de leur écrire une plainte (bien méritée) à mon retour au pays; en ne tenant pas leur parole, ma banque m'a mise dans un sale pétrin. Heureusement, Za est venue à mon secours grâce à la magie du virement Interac et tout est retombé dans l'ordre.

J'ai une chambre très correcte au troisième étage, avec une vue très « bof » (de mon balcon, je vois des toits en bardeaux  ), mais on s'en fout un peu car je vais passer tout mon temps ici en salles de conférences à débattre avec mes amis et collègues ici.

J'ai pris un peu de temps pour parler à Za, Vayda et Ludo, puis j'ai écouté une partie de Tout le monde en parle à la radio Web, car la télé québecoise n'est pas accessible en ligne des États-Unis, du moins pas par des voies légles. L'émission recoit entre autres LP cette semaine; Za, Vayda, Jess – une amie de Za et de moi par ricochet – et moi sommes allés la voir à Montréal jeudi cette semaine, et ce fut un très bon spectacle, LP est très généreuse sur scène.

Je commençais à vraiment m'endormir, mais il était un peu tôt et je n'avais pas mangé. Je suis allé à l'épicerie chercher fruits, légumes, un peu de fromage, des croutilles et de la bière pour les fins de soirée. J'ai constaté que le volcan est à 96 miles de l'hôtel. Eh ben... J'ai mangé un peu, par principe.

Tout ça avant d'aller... enfin... prendre une douche. Et dormir...

Jour 0 18 février 2019

Décalage horaire et fatigue font étrange ménage, mais je me suis levé versh 45 heure locale (ce qui ressemble à mon horaire normal). Je devrais me replacer rapidement, mais le corps souffre un peu du voyage ce matin. Douche pour le réveil, puis je me mets à la lecture de certains documents en vue de dossiers chauds prévus à l'horaire de la journée.

Un horaire normal d'un journée au WG21 va comme suit : début des travaux àh 30, courte pause café de 10 h 30 à 10 h 45, pause dîner de 12 h à 13 h, pause en après-midi de 15 h 30 à 15 h 45 etet fin des travaux de jour vers 17 h 30 pour reprendre les travaux de soirée de 19 h 30 à 22 h. Les pauses sont importantes : c'est très intense, et le cerveau fait mal après un moment; le réseautage est important car nous sommes répartis en plusieurs salles de travail et il se passe des choses qui nous intéressent ailleurs, alors ces moments servent à partager les informations, et les gens qui doivent retravailler leurs propositions peuvent le faire pendant la pause du dîner ou celle du souper (ou après la séance de soirée, ce qui arrive pratiquement chaque jour, sauf peut-être le vendredi car les décisions lourdes sont typiquement prises le vendredi après-midi, en plénière).

À Kona, dû au climat et à la prédilection de la majorité pour le temps chaud (vous me connaissez : je préfère le temps froid, mais je suis dans la minorité  ), nous débutons les travaux àh pour donner une soirée un peu plus longue (tout se décale d'une trentaine de minutes).

J'ai fait un peu de jonglerie administrative pour les finances (car j'ai du soutien, et j'en suis reconnaissant; je dois aussi dire que le service à l'hôtel est excellent), et je pense que je pourrai rapidement rembourser mon épouse pour son coup de pouce d'hier, ce qui ramènera la situation à la normale. Merci à Yasmine, en particulier, qui est mon ange gardien pour tout ce qui est administratif lors d'un voyage comme celui-ci.


La salle de plénière combine deux salles de bal.On doit être entre 130 et 140 participantes et participants ce matin, à l'oeil. Il y a de l'eau, mais pas encore de café (brrrr...). Il y a de l'enthousiasme dans la salle.

Nous commençons par l'accueil normal : un bref mot de notre hôte, un bref rappel des procédures et du code de conduite, l'organisation des lieux et l'accès au café, etc. Un rappel un peu embêtant pour moi est que nous ne sommes pas supposés laisser filtrer ce qui se passe pendant la semaine; il se peut que je ne puisse pas faire de mises à jour quotidiennes de cette page comme je le fais habituellement.

Note : j'ai consulté Herb Sutter (le Convener pour WG21) à ce sujet sur l'heure du dîner, et son avis est qu'il est préférable de faire en sorte que le fruit des discussions ne soit pas rendu public avant la fin de la semaine. Pour cette raison, je vais exécuter un script sur la page qui remplacera les sections techniques par du texte temporaire, et je retirerai ce script à la fin de la semaine.

On a une nouvelle procédure pour la gestion  des numéros de proposition, ce qui prend un peu de temps (nous sommes rendus trop nombreux, et le volume de travail est trop élevé, pour poursuivre la procédure du passé, où une demande à un tiers responsable suffisait).

Pour le reste, c'est la mécanique normale : « tour de table » pour les présentations, procédure de vote, etc. Dû à l'envergure de la participation, seuls les gens qui ont des rôles administratifs sont présentés officiellement, puis celles et ceux dont c'est la première présence ici (une douzaine ou une quinzaine, qui ont droit à des applaudissements). Une bonne nouvelle : même si la population reste majoritairement masculine, la participation féminine s'est accrue un peu depuis quelques années. Les documents administratifs précédant la rencontre sont approuvés (presque mécanique, quoiqu'il y a souvent des ajustements et aujourd'hui ne fait pas exception).

Bjarne Stroustrup nous informe que 2020 sera le 40e anniversaire de C++, un événement important, pour mettre en lumière l'importance de la rencontre de cette semaine. Les votes cette semaine se tiendront samedi, pas vendredi après-midi, pour maximiser l'utilisation du temps vendredi étant donné l'ampleur de ce qui nous attend. Il y a d'ailleurs plusieurs moments où je devrais être à plusieurs endroits en même temps... >soupir!<

Herb Sutter nous informe que WG21 aura 30 ans cette année. Plusieurs participant(e)s sont ici depuis plus de 20 ans, mais très peu depuis plus de 25 ans. Il trace un bref historique des pratiques du comité et leur évolution, mentionnant la tension entre standardiser les pratiques existantes et faire évoluer la science. La maturité du processus montre que pour C++ 20, plusieurs des mécanismes visés sont déjà implémentés et utilisés en pratique; nous nous améliorons! On discute de la capacité de CWG et de LWG de réviser le texte normatif des propositions discutées cette semaine pour être en mesure de livrer le tout à temps.

Je vous épargne quelques échanges techniques, qui recoupent la gestion du temps restant à la rencontre de cette semaine et (pour les formulations chez LWG et CWG) à Cologne cet été, et on confirme certains trucs-clés (dont le fait que Networking devra attendre à 2023, tristement pour les gens comme moi qui ont bien hâte de laisser les sockets du langage C derrière, mais je comprends : il y a des limites au temps disponible pour un groupe de bénévoles, même s'il est de l'envergure de WG21 (car plus de participant(e)s signifie aussi plus de travail, car les gens ici alimentent le comité de travail!).

Je salue quelques personnes au passage, prenant entre autres des nouvelles de Walter Brown que j'apprécie beaucoup, et saluant Anna Dusíková, puis je me dirige vers CWG. Je ne sais pas si je vais passer autant de temps là qu'à l'habitude (c'est un peu ma « maison technologique » depuis quelques années; j'aime beaucoup les gens, le niveau intellectuel, l'humour), étant donné les rencontres de SG14, SG20 et de SG12 (celle-ci en partie conjointe avec WG23), de même que les discussions plus « lourdes » auxquelles ont peut s'attendre autour des coroutines et des contrats cette semaine, mais on va faire notre possible.

Le café est arrivé, mais il n'y a pas de grignotines. On va s'en sortir quand même 

C'est amusant d'être dans une salle de travail, tous concentrés devant nos ordinateurs, à lire et à débattre du contenu scientifique et technique de textes normatifs, et de voir passer dans le corridor des vacancières et des vacanciers en maillot de bain.

Sur le plan technique, les documents qui nous attendent chez CWG portent sur des sujets extrêmement intéressants; dans la plupart des cas, si nous parvenons à les traiter à temps (et si nous ne découvrons pas d'aberrations, car ça arrive), le langage sera meilleur (parfois bien meilleur!) à la fin de la semaine.

Mike Miller met la table pour expliquer la semaine qui nous attend. Nous serons en partie influencés par le débit de traitement qui découlera des travaux chez EWG

P1286R1 Contra CWG DR1778

Richard Smith explique que l'interaction entre les spécifications d'exceptions (noexcept) et =default sur des fonctions spéciales (dont la Sainte-Trinité) provoquent des circularités embêtantes. Le cas de std::atomic<T> est patent en ce sens. L'approche proposée est d'accepter la demande du code client : s'il demande noexcept et =default, alors lui donner, tout simplement. Il recommande aussi de retirer noexcept du constructeur par défaut du type atomic<T>.

Cette situation tient du fait que déterminer noexcept demande une connaissance du contexte entier. L'exemple de Richard Smith est :

struct X { X(); };
struct A {
  struct B {
    B() noexcept(A::value) = default;
    X x;
  };
  decltype(B()) b;
  static constexpr bool value = true;
};
A::B b;

Il manque des informations sur la nature des fonctions spéciales de B jusqu'au point où la fin du bloc englobant (la classe A) est atteint, en particulier dû à A::value qui permet de qualifier la clause noexcept de B::B()

Des questionnements s'ensuivent sur l'impact (ou pas) de cet ajustement sur la trivialité de atomic<T>::atomic()

Notez que « leur donner ce qu'ils demandent » ne change pas l'impact de briser une qualification noexcept :

struct T { T(T &&); };
struct U { T t; U(U &&) noexcept = default; };
U u1;
U u2 = static_cast<U&&>(u1);      // OK, calls std::terminate if T::T(T&&) throws

Aaron Ballman se demande si SG12 a vu ce texte; selon lui, ceci pourrait influencer la fin des programmers (terminate() ou pas, plutôt que d'obtenir une erreur à la compilation). Hubert Tong pense que documenter ce changement serait plus à propos à l'annexe C qu'en tant que DR, mais Aaron Ballman pense qu'un DR serait plus raisonnable sur le plan pratique. Jens Maurer suggère que Aaron Ballman contacte Gabriel Dos Reis informellement pour voir si SG12 préfère y jeter un coup d'oeil, sinon CWG pourrait amener le tout pour vote à la fin de la semaine.

Mike Miller l'apportera en tant que DR à moins qu'il y ait de l'opposition cette semaine.

P1272R0 Byteswapping for fun&&nuf

Isabella Muerte explique sa proposition d'ajouter dans <bit> une fonction std::byteswap<T> qui serait constexpr et inverserait l'ordre des bytes (pas l'ordre des bits) d'un T, avec T entier, en utilisant explicitement std::bit_cast<T> dans les cas où T serait autre chose (p. ex. : un nombre à virgule flottante). La fonction serait de forme template <class T> constexpr T byteswap(T) noexcept

La terminologie est simple, mais l'enjeu est la concordance avec les règles particulières de C++ sur les entiers (qui peuvent être particulières) et avec la possibilité de padding dans un type non-entier.

Hubert Tong mentionne que LEWG n'a pas encore vu cette proposition, donc le nom peut changer d'ici la fin de la semaine. Isabella Muerte dit que LEWG l'a vu par le passé, mais que LWG va devoir le voir aussi. Mike Miller dit que certains aspects terminologiques sont Core-Ish, ce qui explique qu'on souhaite y jeter un coup d'oeil.

Isabella Muerte dit que les nombres à virgule flottante n'ont pas une représentation assez stable pour que byteswap() soit utilisable de manière portable sur ces types. Mike Miller demande si l'intention est de provoquer une erreur de compilation ou d'y aller autrement. Isabella Muerte dit que LWG doit discuter de la manière de procéder. On en discute; c'est par voie de concepts que l'on devrait procéder (il y a aussi une forme SFINAE-Friendly qui est envisageable).

Mike Miller demande une précision sur le recours au terme object representation. Isabella Muerte dit s'être inspirée du texte de std::bit_cast; le plus important à ses yeux est qu'il soit clair que nous inversons des bytes, pas des bits.

Hubert Tong précise que cette fonction retourne une valeur, pas un objet. Richard Smith propose une formule qui semble satisfaire tout le monde (en gros, la valeur de retour a une représentation qui est l'inverse de celle de la représentation de l'objet accepté en paramètre, si je paraphrase). C'est délicat car on ne veut pas laisser entendre qu'on touche aux bits. Hubert Tong parle du cas des tableaux, en particulier. L'enjeu des bits de padding est le coeur des préoccupations.

Jens Maurer trouve une manière d'indiquer que s'il est impossible de déterminer une valeur dans le type de destination qui corresponde aux bytes d'origine (inversés), le résultat est indéfini. Isabella Muerte dit avoir essayé une phrase qui imposait des types de taille paire, mais Nathan Sidwell dit que faire un byteswap() sur bool ou sur char deviendrait indéfini (et Hubert Tong rappelle qu'il existe des bool qui ne sont pas sur un byte). Le problème des types représentés sur plusieurs bytes est plus important.

Faisal Vali rappelle que l'on pourrait faire byteswap(byteswap(val)) pour un T donné et le passage intermédiaire pas du comportement indéfini viendrait tout casser. La salle acquiesce.

On reverra ce texte plus tard dans la semaine, après que LWG y ait jeté un coup d'oeil.

D1091R3 Extending structured bindings to be more like variable declarations

Nicolas Lesser propose de raffiner les Structured Bindings pour qu'elles se comportent plus comme des variables (un peu comme les membres d'un union ou d'un bitfield, donc on ne pourrait pas prendre une référence sur un Structured Binding par exemple), permettant entre autres de les utiliser pour fins de capture dans une λ. L'idée a déjà été approuvée par EWG.

On fait un peu de travail sur la terminologie, mais Jens Maurer l'a déjà travaillé un peu et c'est déjà très bien.

Faisal Vali demande si captured des Structured Bindings par copie dans une λ copie l'objet entier auquel elles réfèrent; Nicolas Lesser confirme que non.

Faisal Vali fait remarquer que EWG a accepté static, thread_local, const, volatile, mais pas inline sur les Structured Bindings. On réfléchit aux raisons... Il faut faire en sorte que deux unités de traduction voient, par accident, des références sur des objets distincts. Il y a des pièges ici, surtout si on souhaite faire une soustraction entre les adresses de deux sous-objets d'un même objet.

La pause du dîner met fin aux discussions matinales. Comme c'est souvent le cas, certains d'entre nous (dont moi) continuons de travailler dans la salle pour poursuivre les travaux pendant la pause.

Je découvre un peu l'hôtel, qui est très grand (et donne effectivement sur l'océan Pacifique). On y trouve un petit centre commercial (pour les touristes), mais qui n'est pas assez proche (ni assez bruyant) pour nuire à nos travaux. J'y ai trouvé des mets préparés (une salade avec un peu de fruits de mer) pour 8,50 USD. J'ai croisé Michael Wong (toujours un plaisir!), qui est comme toujours à la fois le plus occupé et le plus gentil des humains, de même que Andrzej Krzemienski avec qui j'ai échangé par courriel dans le passé mais que je n'avais jamais rencontré en personne.

J'ai profité du dîner pour bavarder un peu avec mon ami Billy Baker, et prendre des nouvelles du déroulement des opérations chez LEWG où il était scribe ce matin; un peu comme moi, il est intéressé par les débats plus lourds sur les contrats, qui occuperont EWG toute la journée, mais préfère attendre que la situation se stabilise avant de se faire une tête.

Je prends les notes pour le début de l'après-midi, Jens Maurer étant occupé par des tâches administratives (la gestion du café décaféiné, pour être honnête). J'en profite pour rappeler le degré de rigueur dans les discussions ici; avec un langage dans lequel on trouve plusieurs niveaux d'abstraction, chaque virgule, chaque caractère d'espacement, chaque police de caractères est importante et demande de l'attention, surtout dans un document où se trouvent des traces de révision (ajouts et suppressions).

D1091R3 Extending structured bindings to be more like variable declarations

Nicolas Lesser a mis sa proposition à jour pendant le dîner.

Mike Miller : dans §9.5p4 la distinction entre lvalue et rvalue arrive trop tard dans le texte

Hubert Tong : à quoi servent exactement les ? Il faudrait s'assurer que le contexte soit présent dans le texte

Mike Miller : le contexte est dans le texte, mais pas dans l'extrait qui nous est présenté

Patrice Roy : a-t-on identifié la raison pour laquelle inline n'est pas sur la liste?

Roger Orr : il faudrait aller vérifier le Wiki chez EWG

Aaron Ballman : a-t-on résolu la question du linkage?

Hubert Tong : nous n'avons pas cerné un problème (ou l'absence d'un problème) avec le linkage et les noms des Structured Bindings, mais s'il y a un problème, il est préexistant et demeure avec le statu quo

Hubert Tong : le terme designated by pour un type détonne avec les usages du standard. Je sais que c'est préexistant, mais ce n'est pas du Core Wording habituel

Hubert Tong : pour quelle raison apparaît-il à un seul endroit alors qu'il y a d'autres occasions?

Nicolas Lesser : le reste est du texte existant, et je ne voulais pas faire un drive-by wording change

Mike Miller : il y a un irritant avec les marqueurs d'insertion et de suppression dans §10p8 (Nicolas Lesser corrige)

Je redonne le contrôle à Jens Maurer vers 13 h 33. Mike Miller explique à Nicolas Lesser la procédure pour attacher une proposition à la page de celles proposées pour fins de vote à la fin de la semaine.

P1041R3 Make char16_t/char32_t string literals be UTF-16/32

R. Martinho Fernandes se joint à nous. Ceci devrait officialiser le fait que u"allo" utilise la représentation UTF-16 et que U"allo" utilise la représentation UTF-32 (le substrat de chacun, char16_t et char32_t, est déjà standardisé). Ceci rejoint le fait que u8"allo" utilise UTF-8, une étape importante vers le support d'Unicode.

Aaron Ballman demande si l'ordre des bytes doit être spécifié, mais c'est déjà déterminé.

Jens Maurer fait remarquer que Aaron Ballman, en tant que liaison vers WG14, devra s'assurer que cette proposition soit aussi traitée là-bas. Aaron Ballman indique que le standard C a des macros pour indiquer le comportement dans ce cas; R. Martinho Fernandes dit que C++ « ramasse » cette option par la bande, mais qu'il ne connaît aucune implémentation profitant de cette flexibilité. Jens Maurer dit que nous sommes en droit de décider qu'une option valide en C est la seule possible en C++. Aaron Ballman mentionne que ce code peut être dans un en-tête partagé entre les deux langages, et que du fait que c'est des littéraux, il craint des ennuis. Jens Maurer pense que recourir à #error dans le cas où le code C dérape du point de vue de C++ est une pratique raisonnable.

On passe un peu de temps sur l'écriture décrivant le tableau de valeurs UTF-16 ou UTF-32 successives servant de substrat à la représentation des littéraux. Ça nous fait réaliser que la partie du standard sur les littéraux représentant du texte aura besoin d'un peu d'amour avec les multiples transformations encourues par le passage au support d'Unicode qui résultera, éventuellement, des travaux de SG16. Entre autres, dans le texte, il y a mention de single c-char qui, sans manquer d'intérêt d'un point de vue Unicode, serait probablement mieux décrit avec une note non-normative.

Hubert Tong aborde la question de la taille de la chaîne, qui ne tient pas compte du délimiteur, mais ça semble être la définition normative depuis longtemps.

Aaron Ballman demande si une note dans la section propre à LWG devrait clarifier le comportement lors d'interaction avec C. Il pense qu'il pourrait être utile de faire en sorte que si <c8char> est inclus, la macro qui impose le comportement de C++ soit définie à une valeur que nous choisissons, du moins pour un programme C++. R. Martinho Fernandes dit que lorsque SG16 a mené son étude sur le comportement des implémentations, une seule semblait diverger de ce comportement. Hubert Tong recommande de poser cette question à SG16.

On amènera celle-là pour vote samedi.

D1139R2 Address wording issues related to ISO 10646

Ce texte de R. Martinho Fernandes porte sur la terminologie utilisée pour discuter d'Unicode dans le texte du standard.

Hubert Tong discute d'une subtilité terminologique qui laisse entendre (indirectement) par whose dans ...is that character whose code point short identifier... laisse entendre (en anglais) qu'il n'y en aurait qu'un seul, alors qu'il pourrait y en avoir plus, et suggère qu'on change les whose par des that has.

Un paragraphe comprend quelques notes non-normatives sur la nature de certains types de caractères. On discute de les grouper ensemble pour faciliter la consultation. Hubert Tong soulève que pour les caractères UTF-8, encodées sur un octet, les valeurs de 128-255 sont techniquement représentables au sens d'une valeur même si elles ne sont pas représentables en tant que code units UTF-8 valides. Il faut faire très attention aux nuances entre byte, octet et UTF-8 code point.

On passe près d'une trentaine de minutes à discuter de la représentation correcte en texte normatif des intervalles de valeurs d'un caractère Unicode. Juste discuter d'Unicode implique au moins trois ou quatre niveaux d'abstraction (code point, code unit, character, glyph, j'en oublie sûrement) et exprimer ceci dans le texte normatif qui comprend lui aussi plusieurs niveaux d'abstraction (plus d'une dizaine) est... un défi.

On amènera celle-là pour vote samedi.


Hubert Tong mentionne que Richard Smith souhaitait discuter d'un changement appliqué de manière éditoriale, mais qui introduisait une défectuosité. Ou nous trouvons une solution, ou les éditeurs inverseront le changement en question.

Il ne reste que quelques minutes pour discuter de trucs avant la pause. Jens Maurer suggère qu'on examine la définition de la précision des entiers, où notre terminologie (range exponent) diffère de celle de C. JF Bastien a suggéré de standardiser sur ce que C utilise, du fait que leur terme est préexistant et que le nôtre est récent. Hubert Tong mentionne que la définition de width en C pose problème (un cas de off-by-one) dans le contexte de C++. Aaron Ballman relit la définition existante, et C semble faire une distinction entre precision (qui n'inclut pas le bit de signe ou le padding) et width (qui les inclut). Sur cette base, standardiser sur width en C++ semble correct. Jens Maurer craint (mais très légèrement) une confusion avec width of bit-field, car le contexte semble clair. Le changement sera fait sur une base éditoriale, du fait que ce changement n'impacte pas le standard dans sa forme publiée la plus récente.

On prend la pause à 15 h. Journée très intéressante, ça progresse bien, mais le café sera le bienvenu. Gor Nishanov passe; avec les discussions sur les coroutines, qui s'annoncent très intenses (mercredi, si je ne m'abuse), il semble complètement avalé par le travail. J'espère qu'il pourra dormir tranquille à la fin de la semaine, il le mérite!

Jonathan Caves me parle d'une pratique cauchemardesque que C utilise pour simuler l'héritage, et qui complique sa vie dans l'implémentation des modules : inclure (ou pas) les membres d'un struct sur la base d'une macro, définie dans certains contextes mais pas dans d'autres. Brrrr...

On reprend les travaux.

P0883R3 A Proposal to add stacktrace library

Antony Polukhin nous amène cette nouvelle révision d'un mécanisme d'exploration de la pile d'exécution.

Jens Maurer rappelle que le gros enjeu par le passé était la définition formelle de stack trace, surtout du fait que la machine abstraite de C++ ne parle pas de pile d'exécution (pour d'excellentes raisons, d'ailleurs)

Nathan Sidwell dit comprendre que la forme du stack frame lors de l'appel d'une fonction inline est implementation-defined; il y a une différence entre la réalité des implémentations et l'abstraction du langage, qui est capable de supporter des architecture (existantes!) où le concept de pile d'exécution serait non-trivial à exprimer.

John Spicer fait remarquer que le instruction pointer retourné par stack_frame::address() peut ne pas être représentable par un void*. Aaron Ballman se demande si même un intptr_t pourrait être utile dans ce cas. Hubert Tong dit qu'on peut dire que c'est implementation-defined, mais que c'est peut-être non-représentable dans un programme. Jens Maurer dit qu'il faudrait quand même donner un cadre pour définir (en quelque sorte) les limites du implementation-defined et ce qu'on peut faire avec un pratique. On se demande s'il faudrait renommer la fonction, par exemple stack_frame::instruction_pointer() ou stack_frame::code_address(), ou encore l'accompagner d'une note non-normative (on mentionne code_location, qui serait différent de source_location et qui aurait un sens distinct).

Antony Polukhin rappelle que la fonction risque d'être non-atomique (au sens informel du terme) et représenter plusieurs instructions. Jens Maurer rappelle que la valeur retournée se veut utile, mais demeurera une approximation pour aider les usagers, étant pas nature informelle.

Hubert Tong soulève la question de terme invocation sequence, qui semble supposer l'existence de fonctions mais peut ne pas convenir à des constructeurs ou à des destructeurs des objets globaux. John Spicer rappelle que c'est une approximation de la réalité, mais c'est un problème dans le texte; on le corrige (en gros, l'invocation 0 qui concerne ce qui précède main() précède aussi celles dont on parle dans le texte).

Aaron Ballman lit sur un canal IRC que certains craignent la confusion associée avec le terme stack frame, qui peut prendre un sens différent avec les coroutines. Nathan Sidwell rappelle qu'on parle ici d'une représentation d'un stack frame, pas d'un stack frame en tant que tel. Aaron Ballman mentionne le cas de std::type_info qui n'est pas un type. Patrice Roy suggère std::stack_frame_info pour que la terminologie amenée ici concorde avec l'existant.

Dawn Perchik mentionne qu'on décrit ce qu'un stack frame contient mais pas ce que c'est.

Hubert Tong rappelle que les adresses de code et de données peuvent être des réalités matérielles très différentes, et qu'il faut être prudents avec le concept décrit ici. En particulier, l'adresse décrite par un pointeur nul ne pourrait pas être une adresse correcte pour le code, mais en pratique pourrait être correct pour une fonction sur une architecture donnée; utiliser un void* introduit une situation inconfortable. John Spicer rappelle l'existence d'architectures segmentées, où retourner une paire base+offset serait plus utile.

Nathan Sidwell mentionne que retourner l'adresse d'une fonction sera... confus, disons, dans le cas d'une fonction récursive (elles seront toutes pareilles). Antony Polukhin pense que dans ce cas, la chaîme complète de pointers d'instructions est probablement plus ce qui est intéressant pour les usagers. David Olson demande quelles sont les conséquences de n'avoir que des adresses égales dans ce cas. Antony Polukhin demande ce qui est attendu de la part des usagers. Antony Polukhin indique que la comparaison de deux stack_frame repose sur l'opérateur <=>.

Nathan Sidwell mentionne qu'avec le texte existant, il est possible d'avoir plusieurs stack frames distincts qui comparent à true avec l'opérateur == ce qui est effectivement une conséquence de la proposition. Il mentionne en particulier le cas des fonctions inline. Ce qu'on discute ici est associé de près avec la capacité des Debug Info offertes par les divers compilateurs, alors on est assez profonds dans le technique.

On discute de cas où un thread décoderait les informations du stack trace d'un autre thread. Antony Polukhin semble d'avis que la situation est impossible, le sens des intruction pointers retournés étant local. John Spicer explique sa perspective en traçant un parallèle avec les débogueurs existants, étant d'avis qu'on opèrerait sur une copie (un snapshot) de l'état du programme, pas sur le programme.

Nathan Sidwell fait remarquer que le modèle proposé rend coûteux l'exploration d'un stack trace avec des fonctions inline. Antony Polukhin dit que son avis est que le code client ne voudra pas explorer le stack trace à son point d'acquisition. Nathan Sidwell pense que l'API proposée manque de flexibilité dans ce cas. Jens Maurer se demande si on déborde de notre mandat. Jonathan Caves explique sa perspective, liée au .PDB de Microsoft; Nathan Sidwell le rejoint mais pense que la proposition ne rejoint pas cette partie de la réalité des programmes. John Spicer pense encore que ce qui est proposé est implémentable. Nathan Sidwell pense que travailler à partir des adresses de retour pourrait être une approche viable. On pourrait distinguer les fonctions dans une séquence récursive par leur indice dans la séquence d'appels.

Hubert Tong demeure préoccupé par le fait que les accesseurs (apparents) semblent avoir des préconditions qui ne sont pas mentionnées. Jens Maurer pense que la représentation d'une copie de la description la pile d'exécution contourne ce problème, et qu'on pourrait entreposer les informations obtenues pour lecture ultérieure. Antony Polukhin confirme que ces accesseurs sont Read-Only, mais David Olson ajoute qu'elles ne sont pas légères. Nathan Sidwell dit que le point où ces opérations coûteuses seraient faites est précisément un point où on préférerait éviter de tels coûts.

Mike Miller demande quelle est la position de CWG.

Roger Orr trouve utile la distinction qui se dessine entre le stack trace physique et le stack trace logique. Hubert Tong pense qu'il faudrait documenter les cas de problèmes reposant sur autre chose qu'un manque de mémoire (p. ex. : sur l'absence de Debug Info dans des fichiers accessoires pour les implémentations qui en dépendent). Nathan Sidwell demande que LWG soit consulté pour ceci.

Antony Polukhin trouve un moyen, avec la proposition existante, de distinguer des fonctions dans un cas d'inlining, à travers la fonction globale to_string().

Jens Maurer revient sur address(), et se demande si nous avons un consensus pour le nom (source_location ou autre serait-il préférable?), et sur le type de retour (void* est-il adéquat?). Aaron Ballman revient sur stack_frame ou stack_frame_info, qui devrait passer par LEWG, pour garder une distinction entre ce descriptif et les réalités différentes des coroutines. Nathan Sidwell indique qu'il y a une correspondance 1:1 entre certains aspects de stack_trace et de source_info.

On discute de la comparaison à l'aide d'opérateurs relationnels. Antony Polukhin nous fait comprendre sa perspective, et on le rejoint.

Dawn Perchik revient sur la question de la nature d'un stack frame. On discute. Antony Polukhin décrit un wrapper autour d'une adresse. On se demande quelle adresse. Mike Miller se demande s'il s'agit d'une adresse dans l'appelant ou dans l'appelé. Jens Maurer dit comprendre que que cette adresse n'est pas celle qui correspond à l'endroit en mémoire où on trouve les variables locales, car on parle d'une API statique alors que les appels (récursifs ou pas) sont dynamiques. Roger Orr regarde ce qui est fait par certaines implémentations; ce qu'il trouve est différent, et navigue la chaîne dynamique d'appels pour repérer les adresses de retour.

Ce qui semble clair est que le nom proposé pour ce mécanisme est trompeur, à la fois pour address() et pour stack_trace. On suggère de renommer stack_trace en invocation_record, et de garder address() qui est plus raisonnable dans ce contexte. Hubert Tong dit que le nom invocation_record ne fait pas assez statique à ses yeux; on jongle avec invocation_info.

Patrice Roy dit que void* lui semble être problématique; il préférerait un type non-spécifié mais dont les propriétés opératoires seraient explicitées. Antony Polukhin dit que LWG a demandé spécifiquement que ce type soit spécifié. On jongle avec un entier, mais même intptr_t peut ne pas convenir pour décrire des adresses représentables dans une machine. Mike Miller suggère de définir ce type un peu comme on le fait avec std::exception_ptr. L'idée d'en faire un type opaque (mais spécifié) dont on définirait les propriétés opératoires fait son chemin. Hubert Tong se demande si on a même besoin de la fonction address(); Antony Polukhin dit que ce serait utile pour fins de Caching. Hubert Tong dit que si on peut faire du hashing sur ce type, dans la mesure où ce type qualifie à titre de value type, les cas d'utilisation envisagés seraient couverts.

Jens Maurer trace un parallèle avec native_handle() dans les fonctions touchant aux mécanismes de multiprogrammation. Patrice Roy pense que la situation est différente (native_handle() servant à utiliser des mécanismes qui ne sont pas dans le standard), mais Jens Maurer est d'avis que les systèmes d'exploitation peuvent offrir des mécanismes propriétaires pour lesquels avoir au moins une représentation entîère d'une adresse est un pré-requis minimal.

On discute ensuite des références au mot stack, qui ne représente pas réellement ce qui est fait ici; le terme invocation chain (ou backtrace, mais ce nom est associé à une implémentation particulière et peut devenir un irritant politique) est plus près de la réalité, mais ne décrit pas la réalité. Roger Orr pense que LEWG devrait examiner cette question.

Jens Maurer suggère qu'un membre de CWG (Nathan Sidwell, peut-être accompagné de Dawn Perchik) accompagne Antony Polukhin chez LWG et LEWG pour expliquer la situation.

Hubert Tong ajoute qu'il serait probablement sage de faire des fonctions dispendieuses des fonctions globales plutôt que des fonctions membres; il rappelle que LWG est très rigoureux sur cet aspect.

On ferme à 17 h pour le souper. Roger Orr m'offre d'aller manger avec lui, Hubert Tong se joint à nous, et nous allons vers un resto de poisson local non loin de l'hôtel (un peu cher, mais pas dramatique non plus).

Souper du lundi

J'ai pris une salade avec du Ahi (un poisson populaire ici), du sésame, des crevettes panées, du bok choi et quelques autres trucs que je n'ai pas notés. C'est très bon. Hubert Tong prend la même chose que moi et prend une photo de son plat (le mien est identique), alors c'est sa photo que vous pouvez voir ici.

Je me suis permis un verre d'une bière locale, très bonne elle aussi. Notre souper m'a permis de faire, avec mes amis et compagnons de souper, le tour des grandes questions des deux dernières rencontres (auxquelles je n'ai pas été en mesure de participer), alors ce fut à la fois agréable et instructif. Il y a des informations qui circulent mieux dans une rencontre amicale et informelle que dans une rencontre structurée et officielle, évidemment.

Nous revenons ensuite vers l'hôtel, et je me dirige vers la salle où se tient la rencontre de soirée qui porte sur l'interaction entre les travaux de SG15 (Tooling) et des modules.

La séance de soirée débute vers 19 h. J'ai le plaisir d'être assis à côté de Jeffrey Yasskin et d'Aaron Ballman, deux très chics types. Pour une raison que j'ignore, les barres multiprises sont toutes disparues de la salle dans laquelle nous sommes, donc nous devons dépendre de l'autonomie de nos ordinateurs portatifs respectifs.

Titus Winters nous accueille en expliquant que Bryce Adlestein Lelbach prend charge de SG15, du fait que son implication y est telle qu'il est le mieux placé pour ce faire (à tout le moins à court terme). Puisque Bryce Adlestein Lelbach occupe deux rôles de Chair, Titus Winters suggère qu'on lui cherche un remplaçant avant qu'il ne fasse un Burn-Out  .

Bryce Adlestein Lelbach dit que la soirée portera sur l'interaction entre les modules et le Tooling. Les outils ne font pas partie des responsabilités de WG21, mais un TR (Technical Report) pourrait aider à documenter l'état des connaissances, et guider les travaux qui suivront. Bryce Adlestein Lelbach explique le processus d'un TR, et ça semble bien reçu.

Nous aurons quatre présentations ce soir (Ben Boeckel, puis Michael Spencer, puis Gabriel Dos Reis, puis Rene Rivera – ce dernier parle aussi pour Corentin Jabot et d'autres); suivront un échange, et des votes.

La présentation de Ben Boeckel, qui travaille sur CMake, décrit le fonctionnement de CMake avec les modules de Fortran, et vise à expliquer comment cet état de fait pourrait guider nos travaux avec C++. Je vous passe les détails (il y a des schémas et tout, mais le document de Ben Boeckel est public).

Gabriel Dos Reis suit. Il présente les modules comme une opportunité pour le Tooling plutôt que comme un frein. Il dit que tous les nouveaux mécanismes changent nos pratiques de programmation, et que les modules sont une occasion importante en ce sens; il vante la cohésion accrue de l'organisation du code, et parle des liens avec l'analyse statique qui peut gagner beaucoup du fait que les frontières conceptuelles entre les unités logiques deviennent plus claires, mieux définies. Il rappelle que, bien qu'il soit légal de considérer les interfaces des modules comme des en-têtes, ce mécanisme peut être plus porteur que cela (il mentionne trois ou quatre approches); son avis est que les pratiques sont déjà nombreuses, et que nous gagnerions à attendre un peu avant de standardiser une pratique ou l'autre, plaidant pour le maintien d'une ouverture. Gabriel Dos Reis enchaîne sur le format des BMI (Binary Module Interfaces) en reconnaissant que c'est un enjeu à propos duquel il existe de la suspicion. Le quatuor de Gabriel Dos Reis, Nathan Sidwell, Richard Smith et Daveed Vandevoorde co-signe une prise de position invitant à l'ouverture d'esprit : ils ont tous implémenté les modules, échangent sur le sujet, et sont optimistes. Faut, selon eux, accepter le mécanisme et le mettre dans les mains des gens; que les modules puissent être livrés avec quatre des principaux compilateurs aujourd'hui peut paraît être un signe très encourageant.

Michael Spencer apporte une rétroaction sur son utilisation des modules. Selon lui, les modules ne sont pas les « sauveurs » de C++. Il est d'avis que nous ne savons pas vraiment comment profiter des modules. Il pense aussi que la transition du format traditionnel vers les modules n'est pas une tâche banale, et que le chemin de l'un vers l'autre n'est pas clairement tracé. Il a remarqué des incompatibilités entre modules sur la base de macros différentes lors de la compilation de chacun : ceci peut être utile quand c'est délibéré (p. ex. : une version Debug et une version Release du même module). Il suggère qu'écrire une sorte de préprocesseur maison puisse être nécessaire pour progresser; le format a été pensé pour faciliter le prétraitement de ces fichiers, heureusement.

Rene Rivera explique que l'impact des modules sur notre monde sera important. Il craint que donner trop de liberté aux implémenteurs mènera à des problèmes pour d'autres, comme lui, qui développent des Build Systems. À son avis, le côté moins ouvert (que les traditionnels fichiers textes) des modules liera les usagers à une plateforme ou à un vendeur. Il estime aussi que le format non-portable des modules dans leur forme binaire ralentira leur adoption, surtout chez les gens ou les entreprises qui supportent plus d'une plateforme. Il se dit partisan d'un TR pour défricher le terrain et encadrer les travaux sur les modules. Il soumet d'ailleurs un plaidoyer en appui au TR, et suggère une douzaine de pistes de réflexion pour les travaux menant vers ce TR.

Bryce Adlestein Lelbach explique ensuite son objectif, qui est de construire un consensus quant à la mise en branle d'un processus de rédaction d'un TR pour les modules et d'en définir la portée. Ville Voutilainen demande à Herb Sutter le sens d'un TR; Herb Sutter dit qu'on parle d'un essai en langue anglaise, avec des données, des graphiques, des métriques, etc. et qu'il faut une TS pour inclure du code (les TS étaient des TR de type 2 dans le passé, mais les noms sont plus clairs aujourd'hui). Chandler Carruth dit que du code à titre d'exemple est correct pour un TR, mais qu'un TR ne peut pas donner de spécifications pour le code. Herb Sutter dit que les TR peuvent passer avec un seul vote; c'est un processus plus léger que les autres avec lesquels nous devons jongler.

Michael Spencer dit que pour livrer des modules, il faudra un mécanisme pour extraire les interfaces. Quelqu'un demande si le TR sera un document vivant, qui évoluera avec le standard et verra des mises à jour, ou si les directives qui s'y trouvent sont fixées à jamais; Herb Sutter confirme que ce type de document est vivant.

Une question suit sur la publication des interfaces binaires. Corentin Jabot explique les enjeux à ses yeux. Steve Downey se dit d'avis que des lignes directrices seront utiles pour la rédaction d'outils capables de consommer des modules dont les interfaces sont sous forme binaire. Corentin Jabot parle des bibliothèques Header-Only et d'éventuels modules Interface-Only. Gabriel Dos Reis dit qu'il existe des Build Tools ouverts et des Build Tools fermés, et les deux coexistent; les pistes proposées par Rene Rivera lui semblent utiles à la fois à l'interne et à l'externe, et il est favorable à un TR.

Tom Honermann est aussi favorable au TR, mais ne pense pas que ce sera faisable pour 2020. Il est sceptique, surtout pour les gens dont la compagnie est encore à C++ 11 ou pire. Il estime que l'approche (pragmatique selon lui) de Clang est féconde. Herb Sutter demande si livrer le TR après 2020 serait rassurant; Tom Honermann pense que cela ne permettrait pas de réparer ce qui est irréparable.

Gabriel Dos Reis dit que Nathan Sidwell a fait un travail remarquable dans son implémentation des modules, et demande quand il a commencé (Nathan Sidwell dit à peine deux ans). Gabriel Dos Reis demande si quelque chose d'impossible à implémenter lui saute aux yeux, et Nathan Sidwell dit non. Gabriel Dos Reis parle des différences entre sa position d'origine et celle de Richard Smith, et explique comment la liste des différences entre les implémentations a été déterminée, et combien cette liste était aménageable pour en arriver à un consensus viable. Gabriel Dos Reis dit que les implémenteurs savent déjà quels sont les aspects qui peuvent être standardisés.

Chandler Carruth dit comprendre que l'approche en-têtes-modules de Clang plaît à Tom Honermann et que ce dernier craint que l'approche ne soit pas transposable à d'autres implémentations; pour Chandler Carruth, c'est une fausse piste, et la spécificité de Clang était utile pour un cas très niché. Chandler Carruth dit que les autres succès de Clang ont exigé des adaptations importantes et visibles de leur Build System. Ce ne fut pas gratuit. Chandler Carruth rapporte que les changements que Clang a dû faire ont aussi dû être faits chez les autres implémentations. Il y a un impact sur les outils, mais c'est normal. Tom Honermann demande à Chandler Carruth s'il est d'avis que cette approche avait l'avantage de faciliter le début de la transition; Chandler Carruth dit que cette modularisation implicite fut un peu utile, mais pas autant qu'on ne pourrait le penser; il leur a fallu modifier le compilateur et les outils de manière conjointe.

Corentin Jabot tient une position à l'effet qu'il faudrait que les modules, une fois officialisés, tiennent au moins 25 ans.

Titus Winters cite la loi de Hyrum, qu'il paraphrase en disant que tout aspect exposé d'un système sera utilisé et exploité par les usagers.

Steve Downey dit que tous les membres de SG15 pensent que les modules sont implémentables; il pense que certains aspects gagneraient à être mieux spécifiés. Selon lui, C++ offre une promesse implicite selon laquelle C++ fonctionne essentiellement comme C sur le plan de la compilation et de l'édition des liens, et il pense que cette nouvelle promesse que sont les modules entraînera des coûts très importants. Il parle des graphes de dépendances dynamiques, qui diffèrent des traditionnels graphes de dépendances statiques résultat du recours à des fichiers d'en-tête. Il pense que ces coûts devraient être publicisés.

Titus Winters dit que tout ce que WG21 produit a un coût, par définition. Quelques participant(e)s mentionnent ce que font quelques outils populaires en ce moment, et expliquent comment les dépendances sont découvertes au moment d'un Build.

Une personne pose la question à savoir si passer aux modules complique la tâches des débutant(e)s. Gabriel Dos Reis dit avoir fait ces tests; il n'y avait pas, selon lui, de difficulté accrue. Richard Smith dit que l'approche de Clang fonctionne bien dans ces cas (malgré ses problèmes). Quelqu'un mentionne que l'ordre des fichiers dans une compilation à la ligne de commande pourrait devenir important. Nathan Sidwell dit que pour un Build de projet réel, il n'y a pas de différence. Quelqu'un indique qu'avoir deux modes (génération implicite, génération explicite) peut être une solution.

JF Bastien dit avoir compris des discussions chez SG15 que les Build répartis étaient une préoccupation, et se demande pourquoi ce sujet n'a pas été touché ce soir. Bryce Adlestein Lelbach se dit d'accord que c'est un sujet important mais estime que le temps va manquer aujourd'hui.

Isabella Muerte dit que les programmeuses et les programmeurs C++ ont été habitué(e)s à une évolution qui ne cassait pas le code existant; le passage aux modules est un changement radical en ce sens. Elle exprime des réserves sur plusieurs aspects techniques du problème. Un échange s'ensuit sur la compilation répartie, mais c'est un dialogue entre deux personnes qui ne s'écoutent pas mutuellement; Gabriel Dos Reis fait remarquer que certaines présuppositions de la position mise de l'avant par Isabella Muerte semblent fausses.

Chandler Carruth revient sur la possibilité de changements importants au modèle de Build. Il ne pense pas que la supposition d'une obligation de tels changements soit en fait une nécessité (cela va se produire, à la demande des usagers, mais ce n'est pas un présupposé de la TS sur les modules). Il parle ensuite des adaptations du système de Build réparti dans son entreprise, ce qui est plus réaliste selon lui, mais n'est pas un problème critique ou insoluble. Divers échanges techniques s'ensuivent sur le sujet.

Rene Rivera dit que le souhait derrière le TR est de minimiser l'impact sur les usagers.

Bryce Adlestein Lelbach passe au vote pour un TR. On discute du temps qu'on se donnerait pour livrer ce document. Certains se questionnent sur la valeur d'un vote dans une séance de soirée; Ville Voutilainen indique que c'est un vote du type Feel of the Room, pas un vote officiel de WG21. Herb Sutter se dit fortement favorable à de tels votes, pour éviter que le fruit des discussions ne tombe dans l'oubli. Le vote est très favorable, mais une voix (d'un implémenteur) est contre, sur la base que cela risque de donner naissance à des suppositions ou à des attentes qui seraient déconnectées de la réalité ou qui seraient basées sur les forces et les faiblesses d'une implémentation ou de l'autre, donc qui ne seraient pas représentatives des modules en tant que tels.

Après les remerciements d'usage, nous nous dispersons. Je retourne à ma chambre pour mettre en forme cette page Web, et je prends un morceau du fromage que je me suis acheté hier (un fromage au raifort, sans blagues, car j'étais curieux, et ça goûte ce que c'est supposé goûter... Pas sûr que ce soit bon, mais j'étais curieux et là, je sais).

Si vous lisez ceci alors que les blocs techniques sont remplacés par du texte explicatif, sachez que les blocs d'origine (qui seront révélés à la fin de la semaine) ne sont pas petits du tout...

Jour 1 19 février 2019

Levé àh 45 heure locale. Prendre une douche, se faire un café, manger une pomme locale (c'est officiel, rien ne bat les pommes du Québec, je le confirme avec plusieurs essais à divers points du globe), et préparer la journée. Aujourd'hui, je devrais passer la journée chez CWG, mais ça va se compliquer à partir de demain (j'ai des rencontres avec SG12, SG14, SG20 et WG23, sans compter les rencontres de soirée).

Il pleut beaucoup cette semaine, mais on ne le voit pas vraiment car il n'y a pas de fenêtres dans la salle où CWG travaille (en fait, il n'y a pas de fenêtres dans toutes les salles où on travaille); on le voit quand on se déplace d'une salle à l'autre.

On commence peu aprèsh, le temps de déterminer dans quel ordre traiter les documents de la journée.

P1323R1 Contract postconditions and return type deduction

Hubert Tong explique qu'il y a un ennui dans la déduction des types de retour et la spécification ds postconditions d'un contrat. Son exemple est :

template <typename> struct Tricky { enum { Nested }; };
template <> struct Tricky<int> { struct Nested { }; };
auto foo()
  [[ ensures ret :
      sizeof(Tricky<decltype(ret)>::Nested) ]] // typename?
{
  return 42;
}

Hubert Tong dit que dans le cas d'un template, il est possible de traiter l'évaluation tardive de l'expression et de spéculer qu'il s'agit d'un type, mais qu'en général c'est plus compliqué car on ne sait pas encore quel sera le type de retour au point où la postcondition est exprimée. Évidemment, la situation est exacerbée si la fonction est récursive.

Il a proposé quatre avenues à EWG, qui a fait un choix, alors nous sommes au point d'examiner la terminologie.

Mike Miller fait remarquer qu'une des phrases proposées contient une triple négation. On retravaille pour que ce soit plus affirmatif.

Richard Smith demande si une postcondition peut référer à la fonction assujettie au contrat; il semble que ce soit bel et bien le cas. On adapte un peu le texte pour en tenir compte.

Faisal Vali demande si une implémentation doit diagnostiquer un type de retour non-déduit dont le constructeur de copie serait supprimé, mais Jens Maurer rappelle que l'optimisation RVO est devenue obligatoire depuis C++ 17, ce qui permet de retourner par valeur des objets incopiables.

Richard Smith soulève le cas d'une fonction constexpr. Hubert Tong pense que si la postcondition n'est pas satisfaite, la fonction ne pourrait pas être appelée dans un contexte constexpr.

Richard Smith fait remarquer que l'on pourrait contourner le problème et faire « comme si » la postcondition était exprimée à la fin de la fonction. Ça semble déplacer le problème, pas vraiment le résoudre.

Hubert Tong fait remarquer qu'EWG ne considère pas « moralement répréhensible » d'utiliser une expression récursive dans une précondition.

Dawn Perchik exprime un malaise quant au recours au terme fully defined dans except that said function is considered to be fully defined within the contract condition car ce terme n'est pas formellement défini dans le texte normatif. Hubert Tong retravaille le texte et on détermine que defined suffit.

Faisal Vali demande si les préconditions de contrats sont assujetties à SFINAE.

On discute pendant plus d'une heure des implications techniques des approches pour résoudre ce problème avec la terminologie choisie. C'est intéressant, mais extrêmement technique, et ça couvre l'évaluation récursive des postconditions; l'exemple soulevé est un cas où la postcondition contient un tableau auquel on accède un indice évalué à la compilation. Il y a une distinction, selon Richard Smith, entre fonction indéfinie et précondition de fonction indéfinie : à ses yeux, la fonction est définie mais sa précondition ne l'est pas.

Dawn Perchik souhaite un exemple incluant un cas incorrect. Hubert Tong propose cette horreur :

int f(char * c)
  [[ensures res: res > 0 && c != nullptr]]; // Ok
int g(double * p)
  [[ensures audit res: res != 0 && p != nullptr && *p <= 0.0]]; // Ok
auto h(int x)
  [[ensures res: A<decltype(+res)>::thingy(res)]]; // ill-formed; type of res unknown

C'est tellement obscur qu'on cherche un truc plus accessible. Richard Smith suggère ceci :

int f(char * c)
  [[ensures res: res > 0 && c != nullptr]]; // Ok
int g(double * p)
  [[ensures audit res: res != 0 && p != nullptr && *p <= 0.0]]; // Ok
auto h(int x)
  [[ensures res: true]]; // error: cannot name the return value

... ce qui semble satisfaire le groupe. Notez qu'ici, le problème est en fait le ; car si nous avions des accolades et un return, la postcondition serait adéquate.

On procède avec cela samedi.

L'heure de la pause – et du café! – arrive. Ce fut très cérébral comme début de journée. Puisqu'il n'y a pas de grignotines à la pause cette semaine (triste; ça fait du bien parfois), je suis allé rapidement à ma chambre manger quelques bleuets (pas terribles, mais ça fait l'affaire), puis je suis retourné au boulot. J'ai croisé Jonathan Wakely avec plaisir; c'est quelqu'un avec qui je m'entends particulièrement bien, et qui est arrivé tard hier soir. Il est très pertinent et très terre-à-terre.

Mike Miller décrit le plan de match pour la fin de l'avant-midi.

P0960R2 Allow initializing aggregates from a parenthesized list of values

Thomas Köppe explique la démarche choisie par EWG. En gros, faut que ça fonctionne comme un constructeur. Un exemple intéressant est :

struct A {
   int a;
   int&& r;
};
int f();
A a1{1, f()};     // OK, lifetime is extended
A a2(1, f());     // well-formed, but dangling reference
A a3{1.0, 1};     // Error, narrowing conversion
A a4(1.0, 1);     // OK

Remarquez que la référence pendante est sur le int généré pour compenser l'erreur de type sur le double; avec des accolades plutôt que des parenthèses, le code aurait été une erreur.

Jason Merrill fait remarquer que le texte proposé ne tient pas compte des NSDMI. Thomas Köppe ajuste en conséquence.

On travaille le texte, qui est étonnamment délicat à écrire étant donné la (relative) évidence de ce qu'il cherche à exprimer.

Richard Smith fait remarquer que () initialise le padding à zéro, pas {}, ce qui est une différence subtile (je ne la savais pas, celle-là).

On jongle avec plusieurs formulations, mais c'est insatisfaisant. Richard Smith finit par suggérer d'inventer un nouveau terme, de manière à extraire ce nouveau cas du reste des (nombreuses!) formes d'initialisation dans le langage et le traiter séparément, au moins pour les tableaux. Ça semble fonctionner, mais on s'aperçoit qu'on peut éviter l'introduction d'un nouveau terme. Jens Maurer rappelle qu'il ne faut pas oublier le cas des tableaux de taille indéterminée.

On arrête à 11 h 31 mais le travail n'est pas terminé. Je fais un peu de travail pour mon ami et collègue Victor Ponce, à qui j'envoie une mise à jour lourde (plus de 120 fichiers) qui inclut ce que j'ai fait à l'aéroport et ce que j'ai fignolé durant les pauses aujourd'hui; j'espère que ça lui rendra service, mais c'est peut-être imparfait (je n'ai pas accès à ses outils, alors je sais que ce que j'ai fait fonctionne chez moi, mais je ne sais pas si c'est transposable à sa plateforme).

Je vais me chercher une salade au commerce de l'hôtel (baies de goji, mandarines, poulet, noix, vinaigrette au sésame), de même qu'un café. J'ai été témoin d'un triste moment qui s'est bien terminé : une petite demoiselle de quatre ans (à l'oeil) est entrée dans un ascenseur sans sa mère et était coincée. Sa maman la guidait pour appuyer sur le bon bouton pour sortir. Heureusement, elles y sont parvenues, mais la petite cocotte a eu très peur.

Je reviens ensuite à la salle de travail de CWG pour parler un peu à mes plus jeunes enfants (Ludo et Vayda) par Skype : avec le décalage horaire, mon dîner concorde avec leur souper. Faut parler tout bas par contre, car plusieurs travaillent dans la salle pour être prêts à la reprise des travaux.

J'ai croisé Lisa Lippincott, toujours aussi pertinente. Elle m'a informé que sa proposition sur le trait décrivant les règles de pointer-interconvertibility (dont on parle depuis plusieurs rencontres!) a franchi LEWG aujourd'hui, et sera – si elle survit à EWG vendredi – dans C++ 20. C'est une excellente nouvelle!

On reprend les travaux.

P0960R2 Allow initializing aggregates from a parenthesized list of values (suite)

Thomas Köppe a travaillé avec Timur Doumler pendant le dîner sur une version à jour du document. Thomas Köppe explique les changements, et rapporte que Timur Doumler a trouvé une erreur grave (qui a échappé à tout le monde auparavant; ouf!) dans la forme du constructeur synthétisé : il ne fonctionnait pas avec des non-références! Richard Smith propose une reformulation qui contourne le problème et qui n'entraîne pas de coûts (au mieux de notre connaissance)... or, on découvre des coûts, soit une copie supplémentaire (observable!), particulièrement dans le cas d'un std::array<T,N> T n'est pas trivial.

Richard Smith suggère une nouvelle approche, pour se coller à la philosophie derrière la proposition. Jason Merrill suggère de procéder comme dans le cas où un constructeur générique accepte un T&& (Forwarding Reference), ce trou noir maléfique, ce qui « transformerait » un T en const T& en pratique et contournerait le problème des valeurs, mais Thomas Köppe fait remarquer que dans ce cas, le constructeur sera toujours viable et les erreurs seront remises à plus tard, ce qui n'est pas l'effet recherché. Roger Orr trace une analogie avec les conversions d'enfant à parent. Jens Maurer a des réserves sur l'introduction (notionnelle) d'un constructeur générique là où il n'y en a pas.

Mike Miller suggère de prendre le texte de l'initialisation avec accolades, puis d'insérer les quelques différences (en particulier, l'absence de Lifetime Extension). Jason Merrill lance à la blague que cela introduirait ce qu'il appelle une Foolish Consistency 

On statue qu'une tournure plus simple (malgré ses imperfections) est un moindre mal pour le moment.

Patrice Roy suggère que la note non-normative, qui mentionne l'interdiction de recourir à un designator avec des parenthèses mais n'en donne pas d'exemple, est perfectible. Jens Maurer propose une reformulation qui conserve cet aspect mais rend l'exemple moins dérangeant.

Thomas Köppe fait remarquer que la nouvelle formulation semble plus novatrice et moins un simili-constructeur, mais Jens Maurer se dit d'avis que l'intention est d'avoir un comportement qui rappelle celui d'un constructeur, pas nécessairement d'avoir un constructeur.

Richard Smith repère un autre paragraphe affecté par les changements sur la table. Thomas Köppe y ajoute les éléments requis, on retravaille un peu. Jens Maurer pense qu'il faut aussi ajouter un cas explicatif dans le paragraphe décrivant les règles de Lifetime Extension. Thomas Köppe procède. On fait quelques autres ajustements pour clarifier le propos.

Richard Smith repère une erreur dans la formulation de l'extension de la vie des temporaires que nous venons de pondre : elle ne couvre pas tous les cas et peut surprendre.

Roger Orr se demande à quel point nous atteignons l'objectif. Aaron Ballman mentionne que nous semblons surtout compliquer (encore!) l'initialisation en C++. Thomas Köppe en vient à suggérer qu'on revienne à EWG pour clarifier l'intention, et les informer des conséquences. On en discute et on se dit que le mandat d'EWG a été réalisé. On amène ça pour vote samedi (à moins qu'EWG ne change son fusil d'épaule en voyant le fruit de nos débats).

Mike Miller demande si un Feature Test Macro serait utile. Aaron Ballman pense que non; Jason Merrill est ambivalent. Thomas Köppe ajoute un cas à la table de ces macros, demande quel nom utiliser. Jason Merrill en suggère un (__cpp_aggregate_paren_init 201902L), on procède.

P1021R3 Filling holes in Class Template Argument Deduction

Timur Doumler explique les liens entre cette proposition et P0960 : les candidats synthétisés pour fins de déduction utilisent un mécanisme analogue, et il souhaitait originalement que la terminologie des deux propositions concordent, mais avec tous les travaux faits sur P0960 cela semble moins important désormais.

L'idée de Timur Doumler est d'utiliser CTAD pour synthétiser des guides de déductions pour les agrégats.

On explore le texte proposé pour essayer d'obtenir une concordance avec l'intention. Comme c'est souvent le cas ici, particulièrement cette semaine, on travaille à plusieurs niveaux d'abstraction. On défriche l'intention et ses frontières.

Patrice Roy fait remarquer que la formulation confond des indices (elle utilise et a des cas pour ). Timur Doumler explique l'intention, mais la notation doit être réécrite pour être cohérente (et compréhensible).

Jens Maurer argumente que CTAD se passe surtout au niveau des templates eux-mêmes, sans tenir compte des types concrets qui serviront de paramètres aux constructeurs, et qu'il est inconfortable avec le texte proposé qui semble chevaucher deux niveaux conceptuels. Mike Miller se dit un peu inconfortable avec cela, mais pas au point de rejeter l'approche, et voit un parallèle avec constexpr. John Spicer se rapproche de Jens Maurer. Mike Miller propose un ajustement à la formulation, ce qu'appuie Jason Merrill. Sur ce point (le traitement des classes de base dépendantes), il semble y avoir un consensus.

Mike Miller demande de mettre en relief les différences. Jason Merrill dit qu'il souhaite voir explicité ce qui est exclu des classes de base dépendantes. John Spicer souhaite voir explicité qu'un parent privé fait d'une classe un non-agrégat.

On retravaille la formulation pour mieux gérer le cas d'un agrégat vide (qui est un cas dégénéré dans ce cas-ci, mais dont la possibilité pollue le texte).

Patrice Roy s'interroge sur une partie de la notation, qui indique qu'un constructeur avec parenthèses sera synthétisé (ce qui semble référer au travail de Thomas Köppe, dont nous avons discuté plus tôt), mais Timur Doumler confirme que c'est bel et bien l'intention.

Nous prenons une pause vers 15 h pendant que le travail de réécriture se fait. J'ai croisé Botond Ballo et Stephen Michell en allant me chercher un café, alors nous avons bavardé (brièvement). J'ai aussi échangé avec Herb Sutter, qui dit avoir compté environ 155 participants lundi (mon estimé était donc un peu conservateur, mais je me suis fié sur la liste des inscrits, pas sur les gens effectivement dans la salle).

J'ai une fringale, et je m'endors (grosse journée!), alors je vais au commerce pour acheter des noix locales au chocolat. Je vois le prix : 13,99 USD. Absurde. Je remets le sac sur l'étalage et je retourne travailler.

Nous reprenons les travaux.

P1021R3 Filling holes in Class Template Argument Deduction (suite)

Timur Doumler explique les ajustements faits pendant la pause.

Ville Voutilainen fait une entrée pour voir si nous sommes préoccupés par P0960. Mike Miller et Jens Maurer disent que non : nous avons travaillé fort pour « enterrer » nos préoccupations, et pour atteindre l'intention véhiculée par EWG. Ville Voutilainen s'en va avec un sourire.

On revient sur le texte de Timur Doumler. On discute l'initialisation par défaut des membres résiduels d'un agrégat; en discutant, Timur Doumler fait le constat que c'est imparfait, mais se rapproche de son intention. En examinant divers cas limites, on semble s'entendre que l'intention est rejointe par le texte, du moins quand les types sont soit dépendants, soit default-constructible.

Le reste de ce texte sera discuté avec Mike Spertus ultérieurement (c'est une proposition avec co-auteurs, et Mike Spertus préfère être présent pour articuler sa partie).

D1390R1 Suggested Reflection TS NB Resolutions

Axel Naumann nous met en contexte et décrit le chemin suivi par ce document jusqu'ici. Certains des NB Comments ont été rejetés par EWG déjà, mais il en reste beaucoup à traiter ici.

On y va un NB Comment à la fois. Axel Naumann explique la manière dont la TS a été construite (c'est compliqué : l'enjeu est administratif, à savoir sur la base de quels documents la TS est construite). Le changement administratif demandé est d'une difficulté colossale. John Spicer dit que c'est beaucoup trop lourd, et qu'il serait plus simple de tout baser sur C++ 20 après publication. Aaron Ballman fait remarquer que si la TS est basée sur C++ 14 (ce qui est demandé, pour des raisons administratives), elle ne sera jamais utilisée.

John Spicer fait remarquer un problème de numérotation (deux documents successifs avec des dates différentes, mais avec le même numéro d'identification).

CA001 : éditorial

CA002 : éditorial

US003 : éditorial

CH004 : voir GB086

CH005 : une approche alternative, en lien avec CH006, est préférée... Jens Maurer pense que Axel Naumann a raison, il faut rejeter celle-ci

CH006 : ... mais rejetée (on rit un peu de l'incohérence). Axel Naumann dit être ouvert à nos recommandations, mais pense que les déclarations dont on parle ici peuvent référer à bien d'autres choses que ce que recommande de NB Comment. Jens Maurer suggère d'enrichir l'exemple pour clarifier le propos. Hubert Tong pense que l'exemple proposé ne suffit pas, et ajouterait un commentaire pour en clarifier l'intention. On discute

US007 : Axel Naumann recommande d'accepter sur une base éditoriale

CA008 : Axel Naumann recommande d'accepter, mais avec modifications (l'exemple proposé est invalide selon lui). On corrige le texte proposé (erreurs mineures)

PL009 : Axel Naumann recommande d'accepter, mais avec modifications (implementation-defined deviendrait unnamed). Axel Naumann dit que cette suggestion de Jens Maurer permet de simplifier le texte

CH010 : Axel Naumann recommande d'accepter ce changement grammatical qui permettra reflexpr(A::template B<>). Ça semble pertinent

CA011 : Axel Naumann recommande d'accepter ce changement grammatical, plus imposant. On discute des conséquences du changement pour bien en cerner les contours et les conséquences. Une table avec notes explicatives est proposée; Hubert Tong suggère d'insérer des références de la table vers les notes

CH012 : Axel Naumann recommande d'accepter sur une base éditoriale

CH013 : Axel Naumann recommande d'accepter ce changement normatif

CA016 : Axel Naumann recommande d'accepter ce changement grammatical. Hubert Tong demande si l'ajustement au concept de constante a été fait (les idées de constant et de constant-expression étaient confondues dans la définition des concepts proposés). Axel Naumann n'est pas convaincu que reflexpr puisse atteindre un constexpr. Hubert Tong pense que le texte confond les deux. Axel Naumann et Hubert Tong sont en désaccord sur ce qu'exprime le texte, mais sont d'accord sur la solution (qui semble manquer dans le texte pour le moment)

CA017 : Axel Naumann recommande d'accepter ce changement normatif. L'enjeu est que la réflexivité decltype pose problème en situation de multiples portées

CA018 : Axel Naumann recommande d'accepter sur une base éditoriale

CA019 : Axel Naumann recommande d'accepter ce changement grammatical, qui précise l'impact de la réflexivité sur un parenthesized-expression (constructeur ou appel de fonction?), et permet d'imbriquer plusieurs niveaux de parènthèses

CA020 : Axel Naumann recommande d'accepter sur une base éditoriale

CA021 : Axel Naumann recommande d'accepter ce changement grammatical, mais avec modifications. La liste d'origine était brisée, mais la proposition de résolution était perfectible. Axel Naumann pense que le cas des classes imbriquées n'est pas nécessaire

CA022 : Axel Naumann recommande d'accepter sur une base éditoriale

US023 : Axel Naumann recommande d'accepter sur une base éditoriale

US024 : Axel Naumann dit que celui-ci est plus complexe. Jens Maurer explique que entity at block scope n'est pas clair (ça pourrait référer à des variables extern, par exemple, ce qui ne semble pas clairement refléter l'intention). Hubert Tong pense que name serait préférable à entity dans la résolution proposée, mais Jens Maurer remarque que cela introduirait un ambiguïté et suggère named entity ce qui semble fonctionner

US025 : Axel Naumann recommande d'accepter ce changement normatif, mais avec modification. On retravaille le texte proposé. Patrice Roy remarque que le changement à US024 devrait probablement s'appliquer ici aussi. On semble d'accord

CH026 : Axel Naumann recommande d'accepter ce changement normatif. Hubert Tong pense que le changement proposé ratisse trop large. On ajuste

CA027 : Axel Naumann recommande d'accepter ce changement normatif. Il manquait un cas (celui du functional-type-conversion)

CA028 : Axel Naumann recommande d'accepter sur une base éditoriale

CH029 : Axel Naumann recommande d'accepter ce changement d'exemple, qui ajoute inline à des déclarations de variables constexpr. C'est nécessaire car la base du document précède C++ 20 (et ce sera drôle si on base toujours sur C++ 14). Richard Smith dit que même ici, pour les templates, c'est redondant et devrait être rejeté. On rejette

CA030 : Axel Naumann recommande d'accepter ce changement normatif. Il y avait une dissonance dans le texte qui est corrigé par ce changement. Jens Maurer pense qu'un ajustement à l'idée de constante demeure incorrectement formulé

CA031 : Axel Naumann recommande d'accepter ce changement normatif, mais avec modification. La clarification demandée est raisonnable, mais sous la forme demandée, Axel Naumann craignait que l'entité obtenue perde sa qualité d'alias. Hubert Tong craint que la qualification d'accès soit mal représentée par la résolution proposée. Richard Smith fait remarquer que les phrases en tant que telles ne font pas toujours du sens; on retravaille un peu

CH032 : Axel Naumann recommande d'accepter ce changement normatif. Axel Naumann dit que EWG y a réfléchi, qui l'a envoyé à LWG. L'enjeu résiduel est une question de nomenclatre (p. ex. : Jens Maurer fait remarquer que is_pure_virtual_v<T> est étrange si on contraint T au concept Object comme proposé). Ça va passer à LWG dû au contexte manquant

CH033 : Axel Naumann recommande d'accepter sur une base éditoriale

CA034 : Axel Naumann recommande d'accepter sur une base éditoriale. Hubert Tong pense que c'est non-applicable

PL035 : Axel Naumann recommande de rejeter. L'intention est de parler des fonctions membres spéciales, ce qui explique la forme courante de l'exemple

PL036 : Axel Naumann recommande de rejeter. Le texte lui semble porter l'intention correctement

JP037 : Axel Naumann recommande d'accepter sur une base éditoriale

CH038 : Axel Naumann recommande d'accepter sur une base éditoriale

CH039 : Axel Naumann recommande d'accepter sur une base éditoriale

CH040 : Axel Naumann recommande d'accepter cet ajustement


L'après-midi se termine. Mike Miller demande à Richard Smith si la fusion des modules peut procéder, puisque c'est un objectif plus pressant que la réflexivité pour le contexte de la semaine en cours. Jens Maurer pense que l'on pourrait clore la réflexivité demain matin tôt, puis passer aux modules. Ça lui semble être une sorte de priorité

Thomas Köppe dit avoir trouvé un problème avec sa proposition traitée plus tôt aujourd'hui (une faute grammaticale). Faudra le traiter (rapidement) demain

Souper du lundi

Roger, Thomas, James, Hubert et moi (Jonathan prend la photo; merci!)

J'ai accompagné Jonathan Caves, Roger Orr, Hubert Tong, James Touton et Thomas Köppe pour souper. Je me suis permis un plat de risotto avec une sauce au beurre blanc (très riche) et un poisson local (c'était délicieux). Ce fut accompagné d'une discussion fort agréable; je pense que nous avions cinq nationalités différentes sur six personnes (plus si on compte les multiples citoyennetés), ce qui amène des échanges enrichissants.

De retour pour la rencontre de soirée, deux options s'offraient à moi : algèbre linéaire, et Freestanding (pour les systèmes embarqués). Les deux sujets recoupaient les travaux de SG14, groupe dans lequel je suis très impliqué; avoir pu, j'aurais fait les deux, mais il fallait faire un choix et je suis allé à Freestanding.

Alors qu'on se préparait pour les discussions, JF Bastien est venu me parler d'un resto nommé le French Café, où il y a de bonnes crêpes et où les propriétaires sont Français et au moins une des serveuses est Québecoise. J'y irai peut-être tôt jeudi matin.

Ville Voutilainen anime la rencontre sur les Freestanding Implementations. Ce terme décrit les implémentations partielles de C++ destinées à des systèmes aux ressources limitées, typiquement des systèmes embarqués. SG14 travaille depuis un certain temps sur une spécification plus précise de ce que ceci signifie (le standard donne une « définition » de Freestanding, mais elle est plutôt informelle et il est difficile d'écrire du code portable d'une telle implémentation à l'autre pour le moment).

Je suis un peu surpris de voir qui est présent dans la salle; plusieurs des individus les plus « lourds » politiquement sont ici, incluant la plupart des Chairs des différents groupes d'étude et de travail. Je spécule : c'est probablement pour s'assurer que cette version contrainte du langage ne dégénère pas en une sorte de dialecte dénaturé.

On commence officiellement à 19 h 10.

Ben Craig dit que les questions clés sont de déterminer la plateforme visée (GPU, accélérateurs, microcontrôleurs, noyaux...) et quel est le sous-ensemble minimal de C++ requis pour y arriver.

Ben Craig présente sa perspective des caractéristiques visées, de la plus haute (exceptions) à la plus basse (nombres à virgule flottante). Ville Voutilainen demande pourquoi les destructeurs sont sur la liste (réponse : ODR use et quelques autres trucs). Un autre demande pourquoi les non-lock-free atomics sont sur la liste. Un autre demande pourquoi les exceptions sont un problème sur le GPU. Ben Craig dit que ça implique du Thread-Local Storage, ce qui exclut le développement de noyau. Ben Craig mentionne aussi le fait que les exceptions impliquent de l'allocation dynamique de mémoire. Michał Dominiak indique que le Thread-Local Storage par Thread est assassin. Bjarne Stroustrup dit qu'il existe des implémentations d'exceptions qui évitent ce problème.

Ben Craig dit que RTTI est un enjeu pour la consommation de mémoire impliquée. Quelqu'un demande pourquoi l'éditeur de liens n'est pas assez intelligent pour se débarrasser du superflu. Ben Craig dit que LTO pourrait y arriver, mais ca n'existe pas encore. Michael Spencer dit que ce qui est à gauche sur la diapo pourrait, en théorie, être réglé par LTO, avec de la technologie qui n'existe pas en 2019.

Ben Craig dit souhaiter inclure dans Freestanding tout ce qui ne comprend pas ces éléments problématiques, et l'inclure. Ville Voutilainen dit avoir une implémentation de std::any qui utilise RTTI, et avoir une alternative qui l'évite mais coûte plus cher en espace. Il demande ce qu'il devrait faire. Ben Craig se dit d'avis que la bibliothèque stamdard a très peu besoin de RTTI.

Ben Craig dit que pour les FPGA et les systèmes sans pile, il faut aussi éviter les méthodes virtuelles, les pointeurs de fonctions et la récursivité. Il ne souhaite pas aller là; C99 n'y va pas non plus. Ronan Keryell dit qu'il n'y a pas de processeur sur ces systèmes, mais on peut en ajouter et régler le problème (on rit un peu).

JF Bastien rappelle le point de Michael Spencer et demande si WPO pourrait aider avec les FPGA. Ben Craig dit que c'est une possibilité théorique. JF Bastien dit que si WPO permet de régler ces problèmes, on peut se débarrasser du cas particulier des FPGA. Ville Voutilainen pense que c'est du cas pas cas. Ronan Keryell dit que les vendeurs pour FPGA ne savent pas ce qu'est une fonction récursive.

P0829 est la proposition sur la table. Cette proposition se limite à ajouter (pas retirer) des outils à Freestanding. Elle évite les cas problèmes mais ne se prononce pas sur leur utilisation. Elle retire quelques fonctions (p. ex. : at()) qui ne conviennent pas.

Geoffrey Romer dit que la clé est que Freestanding ne supporte pas les exceptions, et suggère de livrer une implémentation qui fait abort() si quelqu'un lève une exception. Plusieurs répondent que c'est l'état des connaissances. Ben Craig dit que migrer du code de Freestanding à l'environnement complet devrait avoir le même comportement; ce n'est pas la même chose si on passe de abort() à un environnement où try ... catch et possible. Marshall Clow exprime des réserves.

Eric Fiselier dit qu'une bibliothèque à deux niveaux (Freestanding ou pas) migrée vers un client qui a un try ... catch ne verra jamais la différence car le client ne compilera jamais pour Freestanding.

Ben Craig dit que optional, variant, string_view, array et bitset sont acceptables avec ajustements (faut définir ces ajustements). Ben Craig se demande si on devrait livrer ces classes sous une forme incomplète ou pas. Jeffrey Yasskin pense que string_view est essentiel (sinon, on enlève les contrats). Ben Craig se demande si throw doit devenir abort() ou si on doit s'y prendre autrement. Eric Fiselier demande des précisions. Ben Craig pense que les throw devraient devenir des abort() dans les bibliothèques.

Michael Spencer dit qu'on peut ne rien enlever; le comportement existant est de faire terminate() sur levée d'exception dans des cas où les exceptions ne sont pas supportées. Quelqu'un parle de discipline de programmation : les programmeurs peuvent simplement ne pas utiliser les mécanismes s'ils ne leur conviennent pas. Jeffrey Yasskin clarifie que Freestanding peut ne pas supporter d'exceptions, et que le plan est de définir le comportement dans de tels cas

Marshall Clow entend beaucoup parler de bibliothèque, mais veut aborder l'aspect Core. Il demande comment réagir à une erreur à la construction. Ville Voutilainen dit que abort() et terminate() sont des options. Ben Craig ne compte pas apporter de réponses à cette question ce soir, et sa proposition évite cet enjeu. Ben Craig parle en bien des exceptions déterministes, mais c'est pour le futur. Une courte discussions s'ensuit sur les nuances entre abort() et terminate().

Quelqu'un parle des classes qui allouent à travers un allocateur. Ben Craig y a pensé mais n'a pas de solution à court terme; il souhaite aborder cela ultérieurement. Ville Voutilainen rappelle que le seul Pool Allocator standard existant est polymorphique, un problème dans ce cas.

JF Bastien dit entendre beaucoup le mot exception; c'est important, mais à son avis ce n'est pas la clé. Il aimerait qu'on parle d'autre chose. Il se dit d'avis que plusieurs des idées de Freestanding pourraient glisser vers le reste du langage, et aimerait qu'on en parle. Les exceptions peuvent suivre. On ne vise pas 2020 ici.

Bjarne Stroustrup dit que terminate() a deux cas d'utilisation principaux : log and crash et restart. Quelqu'un ajoute que la proposition sur la table, avec abort(), va déjà plus loin que la base usuelle de C pour ces plateformes. Ben Craig indique que C pour Freestanding n'inclut pas memset() et memcpy().

Nathan Myers dit que Freestanding est sur la table depuis des années; ça balkanise le langage en familles d'usagers insatisfaits. Il rejoint JF Bastien dans une quête d'un langage plus satisfaisant pour une majorité. Il dit que même sur une machine pleine de ressources, il voudrait beaucoup de ce que Freestanding cherche à offrir.

Jeffrey Yasskin pense qu'éviter les allocateurs n'est pas une question de ne pas les vouloir. Il voit Freestanding comme une opportunité.

Bjarne Stroustrup reprend le discours de Nathan Myers et exprime une crainte d'une explosion de dialectes, par des groupes d'intérêts qui souhaitent des parties du langage. Il préfère une approche qui construit avec des Building Blocks.

Ville Voutilainen suggère que les dialectes existent déjà. JF Bastien pense que oui. Nathan Myers dit que personne n'implémente ces dialectes. Ville Voutilainen dit qu'un usager peut (en pratique) créer son propre dialecte. Ville Voutilainen dit que ces solutions sont Off-The-Shelf. JF Bastien dit que Freestanding est déjà un dialecte standardisé de C++, aujourd'hui, et dit comprendre que ce dialecte ne convient pas aux usagers; il pense que Ben Craig veut, sans le savoir, un dialecte qu'il estime utile. JF Bastien plaide pour un dialecte qui le serait moins (il suggère des annotations appropriées au contexte, comme [[nodestroy]], ou des mécanismes de contrôle comme consteval). Cela permettrait Freestanding sans fanions de compilation.

Bjarne Stroustrup dit que Freestanding comme proposé, sans extensions, ressemble à du C que personne ne voudrait. Certains disent que oui. Ben Craig se questionne sur la conformité de ces implémentations. Michał Dominiak distingue « extension » et « restriction de l'ensemble des mécanismes offerts »; il pense que le mot « extension » est trompeur. Bjarne Stroustrup dit comprendre le souhait de restreindre l'ensemble des mécanismes utilisés, mais se questionne sur l'ensemble résultant. Nathan Myers dit que les destructeurs sont le mécanisme le plus essentiel. Bjarne Stroustrup dit que les constructeurs et les destructeurs sont l'essence de C++ (c'était là dans les premières semaines); les méthodes virtuelles étaient là dans les premiers mois. Bjarne Stroustrup rappelle que retirer les destructeurs implique une pratique de programmation complètement différente.

Michał Dominiak rappelle que Freestanding est un requis minimal, pas un ensemble fermé : utiliser plus que le minimum ne signifie pas éviter Freestanding. Jeffrey Yasskin pense que Ben Craig cherche à rapprocher Freestanding du langage complet, surtout la bibliothèque standard. JF Bastien dit que plusieurs usagers de Freestanding veulent des choses différentes, et que la même situation tient pour les usagers de C++ en général. Il préférerait que le code dise ce qui est choisi, et que les usagers choisissent ce qui leur sied. Certains de ses usagers de Freestanding veulent de l'allocation dynamique de mémoire, d'autres n'en veulent pas. Cette position reçoit un appui de la salle, mais on relève que l'interaction entre parties d'un programme compilées avec des sous-ensembles non-concordants demeure un problème.

JF Bastien dit que les usagers qui écrivent des noyaux ou des processus pour systèmes embarqués n'ont que peu ou pas de dépendances. Ils n'utiliseront pas Boost de toute manière, et donneront dans le code assembleur au besoin.

Ben Craig souhaite revenir à la bibliothèque. Jeffrey Yasskin dit qu'à son avis, on pourrait tout laisser là, enlever ce qui lève des exceptions, et laisser les usagers choisir. Bjarne Stroustrup demande si inclure un Pool Allocator et un Stack Allocator a été considéré. Ben Craig dit que pour lui, c'est une option pour le futur. Bjarne Stroustrup demande si cela n'obligerait pas les usagers à recourir à des tableaux comme en C. Ben Craig dit qu'ils le font déjà. Bjarne Stroustrup parle d'alternatives.

Chandler Carruth dit apprécier les exemples, mais certains de ses usagers de Freestanding souhaitent C++ sans bibliothèque standard, et il serait inconfortable avec l'idée de briser leur code sans avoir de plan B. Scott Schurr se demandait qui souhaiterait un Freestanding sans allocation; il l'a fait pendant des années, sur des DSP, et dit que C++ était merveilleux pour cela. Bjarne Stroustrup et un autre disent avoir fait quelque chose de semblable pour des avions. C'est utile pour l'ultra-basse latence, ou pour ce qui ne peut pas crasher.

On prend quelques votes. C'est difficile de bien formuler les votes dans les circonstances (c'est un domaine très fragmenté).

Chandler Carruth revient sur le fait qu'ajouter des mécanismes à la bibliothèque standard pour Freestanding lui semble accroître le couplage entre compilateur et bibliothèque, ce qui nuit à ses usagers (qui préfèrent un compilateur sans bibliothèque, et faire des choix par la suite). Il explique comment ils arrivent à livrer un truc minimaliste qui évite même le recours à <cstddef> en exprimant les trucs comme std::size_t à partir de mécanismes du Core Language. Son point est que ces cas d'utilisation (légitimes!) requièrent un plan, et il est d'avis que ce plan doit faire partie de notre démarche.

Michael Wong demande si SG15 pourrait aider à déterminer les ressources minimales requises. Ben Craig se dit d'avis que la séparation entre langage et bibliothèque est un mensonge.

Après les votes, Bjarne Stroustrup fait remarquer que certaines des différences entre les résultats ressemblent à du bruit, et recommande la prudence dans l'interprétation des résultats.

Louis Dionne dit que rendre certains services Ill-Formed n'est pas ce qui se passe aujourd'hui; si on standardise ce souhait, sa plateforme ne pourra jamais supporter Freestanding. Ville Voutilainen dit que les vendeurs livrent quelque chose en fonction de la demande d'usagers; Louis Dionne dit que la salle ne semble pas en contact avec la réalité. Jeffrey Yasskin dit avoir voté sur la base de sa compréhension qu'un vendeur pour livrer plus que ce qui est indiqué. Bjarne Stroustrup se dit d'avis, pour Ill-Formed, que cela provoquera une immense quantité de faux-positifs (les problèmes potentiels ne surviendront pas en pratique). Quelqu'un parle des options avec et sans risques d'exception, et relève que plusieurs types demeureront utilisables, du moins en partie.

Ce fut intéressant à certains égards, mais pas satisfaisants; à mon sens, la nature des votes qui furent pris ne permettait pas de dégager d'information utile. Je pense qu'on a perdu une occasion intéressante; ma position se rapproche principalement de celle de JF Bastien : permettre aux gens qui souhaitent utiliser un sous-ensemble spécifique du langage de l'exprimer dans le code source, plutôt que d'aborder le problème sous l'angle de la bibliothèque (je comprends ce souhait, du point de vue de gens qui réinventent la roue, mais il me semble qu'elle découle de la position que je soutiens).

Je suis fatigué, et je ne suis pas le seul. J'ai bavardé un peu avec mon ami Billy Baker, après quoi je suis revenu à ma chambre formater le texte de la journée. Maintenant : dodo...

Jour 2 20 février 2019

Debout vers 5 h ce matin. La douche est bonne au réveil. Aujourd'hui, je devrais passer la journée à la rencontre conjointe de SG12 et WG23, et la soirée à la rencontre faisant le point sur la situation des coroutines (que je souhaite vraiment voir officialisées pour C++ 20 samedi; mon ami Gor Nishanov a travaillé tellement fort là-dessus... Respect!)

Souper du lundi

Hawaï pour un membre de WG21 (merci à Paul Preney pour la photo)

On me demande souvent à quoi ressemble Hawaï. Paul Preney, un collègue ici, a eu la gentillesse de prendre une photo panoramique pour moi (car je ne suis pas un très bon photographe, n'ayant pas beaucoup d'intérêt pour la chose).

On peut asseoir une quinzaine de personnes dans la salle où je suis ce matin; celle de CWG, où je suis habituellement, est juste à côté. Les deux salles sont identiques, mais celle de CWG peut asseoir quelque chose comme 25 personnes. Les salles de bal où se tiennent les plénières et les rencontres en grand groupe (séances de soirée, EWG, ce genre de truc) ont autant de fenêtres mais sont beaucoup plus grandes.

J'essaierai de prendre une photo de l'extérieur plus tard cette semaine. C'est très beau, mais on n'y va que pour aller souper (aller et retour), faute de temps. Ça fait du bien de regarder à l'horizon, en direction de la mer, après une journée comme celles que nous vivons lors de ces rencontres.

Nous sommes un petit groupe ce matin. Michael Wong sera Chair car Gabriel Dos Reis doit être à EWG.

Michael Wong explique que le plan de match est de couvrir le document de MISRA C++:201X avec un regard d'experts C++. Michael Wong est un standard de facto, ayant été le premier (pas nécessairement le meilleur du genre, mais clairement le plius connu). Ce document est une mise à jour destinée à être publiés à la fin de 2019, et devrait couvrir C++ 17. C'est la première fois que nous sommes consultés pour ce document (la version de Michael Wong ne peut circuler; nous travaillons sur la base d'une projection murale).

Peter Sommerlad dit que plusieurs des aspects discutés dans le document sont des aspect reliés à C plus qu'à C++. Michael Wong explique que le document démarre avec une copie de MISRA C et construit dessus, mais c'est quelque chose qui ne sied pas vraiment à notre langage. Lisa Lippincott signale que les règles de promotion entières sont encore plus complexes et étranges qu'on ne le croit.

Michael Wong explique que MISRA sert beaucoup aux analyseurs statiques, et qu'avec l'avènement des véhicules intelligents, la demande pour une sécurité accrue est forte.

Patrice Roy demande quel est l'objectif officiel du document : dire quoi faire pour ne pas être dans le pétrin ou quoi ne pas faire? La perspective est importante. Michael Wong dit que le document porte surtout sur les pratiques menant à des comportements observables susceptibles d'être consommés par un analyseur statique.

Il y a des règles mandatory (on doit toujours le faire), required (on peut diverger avec justification) et advisory (bonne pratique, informellement). Peter Sommerlad dit que les règles peuvent sembler contradictoires, mais que certaines règles peuvent être « désactivées » ce qui explique un peu la situation. Lisa Lippincott fait remarquer que certains types (par exemple les pointeurs intelligents) mènent implicitement au respect de certaines règles.

Michael Wong nous montre le standard Autosar, aussi important, mais qui est désormais fusionné à MISRA. On discute du niveau de précision / de profondeur attendu. Stephen Michell mentionne qu'avec l'interconnexion croissante des systèmes, un problème local peut devenir un problème global. Patrice Roy demande si ce standard touche la bibliothèque standard, qui joue selon des règles différentes des nôtres (le comportement indéfini est différent à ce niveau); Michael Wong pense qu'on devrait donner un avis à ce sujet.


On va d'abord travailler sur la base du document de WG23. Stephen Michell explique le point de départ de la discussion (ce qui a été fait, ce qui reste à faire selon lui). On regarde le document tel qu'il est; Patrice Roy fait remarquer la terminologie plutôt C du document; Stephen Michell explique que les artisans sont très C et Ada, et que la terminologie en est teintée.

On examine la question des nombres à virgule flottante. Le document de base (général) semble bien couvrir l'essentiel, cette composante étant normée. Lisa Lippincott étant une experte qui siège sur SG6, nous sommes ravis qu'elle soit parmi nous ce matin. Lisa Lippincott propose quelques ajouts au document général, en particulier sur la compréhension... imparfaite des nombres à virgule flottante chez plusieurs. Lisa Lippincott : « there are languages to get things done, and there are languages to get things right ».

Peter Sommerlad fait remarquer que la division par zéro sur des nombres à virgule flottante est du comportement indéfini, sauf si l'implémentation est conforme à IEEE754. Ceci se vérifie à la compilation à travers numeric_limits<T>::is_iec559 pour un type T donné. On essaie d'exprimer une recommandation correcte d'utiliser ce trait. On discute des sortes de nombres à virgule flottante (incluant le très probable short float en vue de C++ 20). On discute aussi de modalités d'arrondis, de conversion (passage de float à double pour un calcul avec retour à float par la suite). On remarque un segment de conversions qui ne s'applique que pour VA_ARGS, donc pour des horreurs comme printf()... Ouf!

On prend une courte pause (enfin du café!). Je bavarde un peu avec Walter Brown, et je me réinstalle pour remettre la main à la pâte. Michael Wong nous explique comment il utilise le changement d'heure pour ajuster ses horaires de téléconférences (c'est un événement très disruptif, alors ça vaut la peine de l'utiliser comme levier).

On recommence. On examine ce qui est écrit pour les énumérations et les énumérations fortes. Le texte de Cs convient pour l'essentiel (dans le cas des vulnérabilités), mais il faut enrichir les exemples pour tenir compte de la surcharge d'opérateurs. Paul Preney donne un exemple avec une énumération sur des semestres. Peter Sommerlad suggère de réduire la portée de la règle recommandant le recours aux énumérations fortes au niveau des espaces nommés, car dans une classe ou dans une fonction, les énumérations traditionnelles suffisent. Lisa Lippincott fait remarquer que notre recommandation diffère de celle de la GSL, mais il se trouve que le domaine d'application (la sécurité) est différent. Patrice Roy suggère que la GSL (à moyen terme) pourrait être teintée ou instrumentée en fonction de domaines d'application; Michael Wong dit partager cette opinion. Lisa Lippincott suggère une formule pour encadrer la spécialisation d'opérateurs arithmétiques sur les énumérations lorsque c'est approprié (c'est limpide).

On examine les pointeurs, les risques de débordements, et une recommandation d'utiliser span quand c'est applicable. On travaille sur diverses formules qui se veulent raisonnables sans être démesurément restrictives. On est surpris de constater que la GSL ne dit pas encore qu'il est préférable d'utiliser des algorithmes plutôt que des boucles (pourtant, c'est un peu partout dans nos livres!).

L'objet de discussion suivant est les références flottantes sur le tas. Peter Sommerlad dit travailler sur un document portant précisément sur ce sujet, et sur des techniques pour réduire les risques de telles fuites. Arherd Plopder dit que l'enjeu de cette section est la réutilisation accidentelle des espaces mémoires devenus disponibles (Lisa Lippincott fait remarquer que ça peut aussi être spectaculaire avec une référence flottante sur la pile)

Pause dîner. Je vais me chercher une salade semblable à celle de lundi (pas très cher, pas loin).

J'essaie d'aider Victor Ponce avec un problème qui, il me semble, correspond à un cas de dépendances malvenues qui sont perçues différemment par Clang (qu'il utilise) et par MSVC (que j'utilise). Ça fait un temps que je sais qu'il y a trop de dépendances entre les fichiers de mon code de doctorat, mais je pense qu'on en est rendus au moment où je dois m'en occuper. J'ai cherché un outil pour visualiser les dépendances; avec Visual Studio, les outils que j'ai trouvés fonctionnaient sur la version Entreprise, que j'ai au bureau mais pas sur mon ordinateur portatif. J'ai fini par aller chercher une version d'évaluation de CppDepend, en espérant que ça aide.

Stephen Michell est venu s'enquérir de l'état de mon doctorat. C'est toujous un plaisir de dire que, modulo les corrections du document, c'est fait  (évidemment, faut que je fasse les satané corrections).

On reprend à l'heure, toujours sur les références flottantes sur le tas. C'est difficile de cerner ce que ça signifie en C++. On cherche un terme commun à tout ce qui peut flotter (potentially dangling, faute de mieux). Vous ne voyez pas tous les échanges ici mais ça prend plus d'une heure. Travailler avec Lisa Lippincott sur un tel dossier est un plaisir, du fait qu'elle a beaucoup réfléchi à ces questions et a une perspective très puissante sur le sujet. Entre autres, on parvient à couvrir le cas d'une fonction comme :

void f(string &a, string_view b);

... où a et b se chevaucheraient (cas que nous recommandons de documenter). Ça prend du temps à pondre (pour très peu de mots), mais ce qui est produit est de qualité. Un truc fascinant est de voir à quel point ce qui est bien pour C peut ne pas convenir à C++.

Pour les débordements sur des entiers, c'est délicat car C++ 20 change beaucoup de choses (on standardisera sur la représentation de complément à deux). Il y a les trucs classiques (déborder sur un entier signé est un comportement indéfini), et on peut référer à C pour les problèmes, mais les solutions possibles sont différentes en C++ (on peut écrire une classe qui détermine le comportement attendu).

Petite pause (enfin du café!). Je bavarde brièvement avec Anna Dusíková qui m'informe que son (excellent!) projet CTRE est considéré en vue de C++ 23. C'est une bonne nouvelle; ce truc-là est brillant, et les techniques de programmation qu'elle y utilise sont superbes.

Je parle un peu par Skype avec ma grande Vayda (Ludo fait déjà dodo). Pour quelqu'un qui voyage un peu, ces outils de communication vidéo par Internet, ça change beaucoup de choses.

Stephen Michell pense qu'on devrait travailler autrement car on avance, mais lentement. La qualité du travail est très élevée, mais la productivité est moins élevée. Demain, avec SG20, certains dont Paul Preney et Patrice Roy s'absenteront, mais nous avons l'impression que SG20 n'utilisera pas la totalité du temps alloué, alors nous pourrons peut-être revenir.

On examine la question du nommage, brièvement, pour regarder l'impact des espaces nommés, puis on revient au débordement sur des entiers et aux recommandations d'usage. Les gens sous-estiment la difficulté de bien gérer les entiers.

L'étape suivante est les opérateurs de glissement que sont << et >>. Pour ça, l'enjeu avec C++ semble couvert par les travaux sur les débordements et par le texte généraliste sur ces opérateurs.

On revient sur le nommage (danger de glissements religieux; le texte existant fait parfois mal aux yeux d'une perspective C++). Quelques trucs spécifiques à C++, comme ne pas débuter un nom par __ (double souligné) ou par un _ suivi d'une majucule (ces mots sont réservés pour la bibliothèque standard), garder les noms en majuscules pour les macros (et les éviter pour les non-macros), quelques conseils d'usage sur la durée de vie, éviter d'utiliser les mots-clés contextuels pour autre chose... On s'entend, heureusement.

Le dossier suivant est les Dead Stores : en C++, on utiliserait [[maybe_unused]] pour ça. Paul Preney suggère de mentionner RAII et le fait que ça ne correspond pas à un Dead Store. Le texte de C est très axé sur volatile alors ce n'est pas vraiment adéquat pour nous.

Michael Wong apporte un cas intéressant :

enum T { S0 =- 13, S1 = 23 };
static eanum T state = S0;
extern void error(); // au cas où il y aurait de la corruption
int f() {
   switch(state) {
   case S0: state = S1; break;
   case S1: state = S0; break;
   default: error();
   }
}
int main() {
   // state = static_cast<T>(3);
   f();
}

Le plan est de se prémunir contre de la corruption de mémoire, mais le compilateur est capable de voir que l'appel à error() ne se produira jamais (sans comportement indéfini) et l'enlève. On peut s'en sortir (par exemple, dans switch(state) peut s'écrire switch(*const_cast<volatile T*>(&state)) et ça peut marcher, mais c'est pas portable). En fait, on essaie de forcer du comportement indéfini pour empêcher le compilateur de trop raisonner.

L'enjeu est vraiment intéressant : on n'a pas de manière claire de simuler une possible corruption de mémoire. Faut réfléchir... Patrice Roy suggère une approche sur la base de contrats, mais Lisa Lippincott pense que ce n'est pas le bon angle d'approche; elle suggère d'y penser comme un bout de code qui tient compte d'un substrat matériel non-fiable. Michael Wong suggère de réfléchir à écrire une proposition pour évaluer les options (nous avons parlé de contrat, de renforcer le mot volatile, et de mettre un mot clé pour dire que le switch doit être potentiellement exécuté... peut-être une annotation, quoique c'est peut-être un peu faible). Peter Sommerlad rappelle que la faute première de cet exemple est sa dépendance envers un état global.

On a fini plus tard, car la dernière question soulevée était particulièrement intéressante et nous pensons qu'il y a peut-être quelque chose de fécond qui s'y cache. Je suis allé me chercher une salade au commerce de l'hôtel et je suis revenu à ma chambre pour contacter ma belle Za qui me manque beaucoup. Il est tard à la maison alors ce fut une brève conversation, mais ça a quand même fait du bien.

Ce soir, nous aborderons l'état de la situation pour les coroutines. J'espère une rétroaction positive...

Je bavarde un peu avec Lawrence Crowl et Anna Dusíková en attendant. Il reste clairement des appréhensions quant aux coroutines (difficultés reliées à la complexité de l'interface, points de personnalisation, inversion de contrôle, etc.). Je fais suivre à Lawrence Crowl une Cheat Sheet qui m'est parvenue il y a une heure ou deux : https://hackmd.io/s/S1H_loeA7# (ça reste effectivement très difficile d'approche pour le moment; si ça passe pour 2020, va falloir travailler sur les idiomes pour simplifier la mécanique en vue de 2023). Lawrence Crowl est comme moi désactive tous les effets visuels dérangeants sur son ordinateur; il m'en envoie une bonne, en grognant sur son interface inefficace : if I notice how cool your interface is, it has failed.

Ville Voutilainen accueille les gens à sa manière, en leur demandant (fermement  ) de s'asseoir, puis présente le thème de la soirée. Il récapitule les points clés : il y avait une quinzaine de propositions (il dit dans quel ordre elles ont été couvertes); les options fondamentales ont été survolées d'abord; les ajustements mineurs ont suivi (incluant un effort de simplification); les votes ont été pris, et il semble que le souhait est (par consensus, avec oppositions) d'adopter la TS telle quelle.

Ville Voutilainen explique qu'après avoir examiné plusieurs options sur plusieurs années, c'est la TS qui est souhaitée. L'enjeu de l'unification de l'approche Stackful et de l'approche Stackless a été abordé sous plusieurs angles. On a statué.

Gor Nishanov relate le devoir que Ville Voutilainen a donné aux multiples auteurs : examiner les options entre eux, faire ressortir les points communs, déterminer une solution aussi unifiée que possible, consulter les vendeurs de compilateurs, et livrer un rapport. Gor Nishanov fait le tour de la question (les documents seront publics : D1493R0 et D1492R0; c'est passionnant, mais bien trop riche pour prendre des notes). Les trois approches atteignent leur résultat, et chacune avait des forces (c'est un rapport très constructif). Un cas d'utilisation particulier est l'implémentation d'un acteur, avec envoi de type Fire and Forget et avec réception. Les défis techniques quant à l'implémentation de ces diverses solutions touchent à deux principaux aspects : la dichotomie Early Split / Late Split (la transformation en automate requiert une taille; la taille est habituellement requise à l'étape de l'analyse statique, alors que l'optimiseur intervient plus tard... On a besoin du sizeof avant que l'étape de transformation en coroutine n'intervienne pour un Early Split), et la détermination de la taille des états à conserver en tant que telle (il se trouve que c'est très difficile à faire). Gor Nishanov nous donne au passage un estimé de l'horizon de temps à travers lequel certains raffinements envisagés semblent (justement) envisageables.

Patrice Roy félicite les auteurs pour l'effort (qualité, quantité) et l'idée d'un devoir qui a mené vers un rapport unifié et constructif.

Quelqu'un demande si on pourrait mettre un Late-Sized Type dans un conteneur. Bjarne Stroustrup dit que tout ce qui ressemble à un tableau est hors de question pour le futur envisageable. Ville Voutilainen parle de la complexité d'en mettre un dans une λ, et du côté ... explosif ... d'essayer de la mettre dans une std::function.

Quelqu'un demande comment d'autres langages implémentent les coroutines. Gor Nishanov fait un tour rapide, et indique que tous ces langages (a) allouent tout dynamiquement et (b) utilisent un moteur de collecte d'ordures.

Geoffrey Romer dit que la difficulté commence si on essaie d'enlever le niveau d'indirection devant les coroutines. La TS, par effacement de types, apporte une solution pratique.

Chandler Carruth dit que les Core Coroutines en version prototype avaient aussi un niveau d'indirection.

Bjarne Stroustrup indique qu'allouer tout sur le tas et de faire une forme de collecte d'ordures remonte à Simula. C++ est 50+ fois plus rapide, ce n'est pas un accident.

Ville Voutilainen rappelle l'expérimentation et la maturité du TS, dans un sens positif (même si ce n'est pas parfait).

David S. Hollman apporte un cas vécu d'apprentissage à l'utilisation de coroutines (à partir de rien) pour faire du HPC, soit la bibliothèque Kokkos (P1403R0). Il nous montre un Fibonacci naïf, écrit sans coroutines (void avec paramètres par référence comme sortants; c'est pas joli et ça fait un peu spaghetti). Il dit avoir lu la TS en un après-midi, faute de documents pédagogiques, et écrit l'équivalent sur la base de coroutines pour en arriver à du code léger, élégant et compréhensible (une fois quelques Wrappers écrits), en plus d'être environ plus rapide. Son impression est que, après l'avoir expérimenté, la TS est prête, et offre véritablement un ensemble minimal de points de personnalisation pour les besoins d'usagers réels. Le gain de vitesse l'a surpris, mais il dit que await_ready() parvenait à escamoter des tests de complétion qu'il aurait fait normalement.

On a un autre témoignage de la salle : quatre heures d'apprentissage, gain de vitesse semblable, et plus simple, plus direct. Gor Nishanov rapporte d'autres cas semblables : les coroutines tendent à donner de meilleurs automates que ceux écrits à la main, car le compilateur voit mieux à travers le code. Eric Niebler dit que chez Facebook, l'expérience a été semblable : beaucoup d'enthousiasme, simplification importante du code existant, et il souhaite faire des flux asynchrones sur cette base. Il dit d'ailleurs voir le Networking profiter de coroutines, raison de plus pour les adopter sous peu.

Nathan Myers demande si on peut contrôler le tas (il dit être ouvert à l'allocation sur le tas... si c'est lui qui la contrôle). Gor Nishanov montre un exemple plein de code, et démontre que le compilateur parvient à réaliser beaucoup de Heap Elision (Halo : Heap Allocation Optimization), résolvant le tout à une constante. Gor Nishanov montre ensuite comment on peut spécialiser new et delete sur le type de promise<T> dans une task<T>.

Adam Martin demande si l'implémentation présume que new n'échouera jamais. Gor Nishanov dit qu'il y a un point de personnalisation pour cela (si on préfère éviter les exceptions). Nathan Myers demande si la taille est une constante manifeste dans le flux d'instructions; Gor Nishanov dit que oui. Botond Ballo questionne le contrat suggéré par l'exemple sur l'allocation susceptible d'être élidée, car il a entendu que c'était impossible à faire. Gor Nishanov dit que Daveed Vandevoorde avait un contre-exemple. Ville Voutilainen précise l'enjeu, et indique qu'avec les λ on a déjà une situation semblable. Bjarne Stroustrup dit qu'il tient beaucoup à ces détails, surtout pour les cas où une allocation dynamique de mémoire pourrait tuer quelqu'un, et propose une manière de le garantir (son truc : s'il y a un new ou un malloc(), provoquer une erreur de lien). Ville Voutilainen pense qu'adopter la TS dans le IS permettra de faire progresser les travaux plus rapidement. Gor Nishanov fait une démonstration de ce que Bjarne Stroustrup suggère. Chandler Carruth propose plutôt d'ajouter un outil post-traduction qui vérifierait les propriétés de ce qui a été généré. Bryce Adlestein Lelbach dit qu'avec des allocations, personne dans son entreprise ne les utilisera. Timur Doumler dit qu'en audio, l'aspect déterministe fait qu'allouer, même potentiellement, rend la TS inapplicable. Ville Voutilainen rappelle que préallouer est possible et déterministe (d'autres sont d'accord).

Les discussions qui suivent sont politiques (le sujet demeure chaud, et les critiques demeurent). Cela dit, il y a beaucoup de positif qui ressort des échanges ce soir.

Ce fut, à mes yeux, une soirée constructive, au sens où j'ai le sentiment que nous avons fait un choix (pas unanime, certains à contrecoeur, mais un choix), et que pour cette raison : nous aurons un meilleur langage, et nous irons de l'avant pour raffiner, améliorer et simplifier l'usager du mécanisme choisi.

Évidemment, le vote officiel sera samedi. La vie peut être pleine de surprises.

Jour 3 21 février 2019

Debout àh 45 comme à l'habitude, douche, café, courriels de la nuit (les humaines et les humains ne dorment pas). Ce matin devrait m'amener à la première rencontre in vivo de SG20, groupe d'étude sur l'enseignement (pour des raisons sans doutes évidentes, mieux vaut que je sois présent).

J'essai un truc fou ce matin : déjeuner. Il y a un petit café à côté de l'épicerie, alors je me prends un café noir (car le premier service officiel ici arrive un peu tard dans l'avant-midi) et un scone à la noix de coco (ici, les principaux produits phares, outre le poisson, semblent être l'ananas, la noix de macadam et la noix de coco). C'est pas vilain du tout, cela dit.

Je croise Christopher Di Bella sur mon chemin. Il est co-Chair pour SG20, et aura donc une journée très chargée. C'est quelqu'un à qui j'ai enseigné à CppCon 2016, et je suis toujours ravi de voir qu'il a la piqûre et s'implique sur plusieurs dossiers, dont sur le comité maintenant.

Je m'asseois dans la salle et je prends quelques courriels, quand Bob Steagall passe me saluer. Je lui demande s'il sera avec nous, il me répond « non, je vais à la rencontre sur l'éducation »... J'étais dans la mauvaise salle. Merci Bob! J'ai eu l'air fou, mais moins que ça aurait pu être.

Nous sommes moins nombreux que je ne l'aurais pensé. Je re-croise Andrew Lumsdaine, avec qui j'ai partagé un panel à CppCon 2017, et j'apprends qu'il a enseigné entre autres à Peter Gottschling, Doug Gregor, Jaakko Järvi et Jeremy Siek. Eh ben...

Jean-Christiaan van Winkel nous accueille. On se présente. Son économiseur d'écran démarre à un drôle de moment; il parle d'un collège qui s'est doté d'un Mouse Giggler pour éviter un économiseur d'écran indésiré. On fait une ronde de présentations.

Jean-Christiaan van Winkel dit que les grosses boîtes ont besoin de programmeuses et de programmeurs C++, mais que c'est trop peu enseigné dans les universités. Paul Preney pense que l'enseignement de C++ est trop souvent de l'enseignement de C. Certains font circuler des anecdotes.

Patrice Roy devient secrétaire versh 25

Jean-Christiaan van Winkel décrit l'ordre du jour. Lita Lo mentionne des ennuis avec la liste de diffusion. Attila Fehér relate les ennuis que nous avons au avec Google Groups. Bob Steagall complète en expliquant la migration vécue par SG14

Jean-Christiaan van Winkel invite les gens présents à s'abonner à la liste de diffusion si ce n'est fait. Il explique aussi le plan de couvrir l'enseignement aux programmeuses et aux programmeurs novices, intermédiaires et avancé(e)s

Paul Preney dit souhaiter partager des trucs et des anecdotes, de succès comme d'échecs

Christopher Di Bella suggère de traiter la proposition d'Isabella Muerte tôt car elle est présente

Attila Fehér parle de l'importance de la compréhension des idées fondamentales

Jean-Christiaan van Winkel suggère la création d'un dépôt de recommandations.

SG20 Charter

Jean-Christiaan van Winkel explique la génèse du document, puis présente un sondage montrant qu'une importante proportion de gens se sont fait enseigner que C++ est « un meilleur C » plutôt qu'un langage à part entière

Jean-Christiaan van Winkel : nous ne voulons pas imposer un curriculum, nous voulons guider celles et ceux qui souhaitent concevoir un curriculum pour C++. Nous voulons aussi distinguer ce qui concerne les sujets pour novices, les sujets intermédiaires et les sujets avancés

Trbea ? : des gens peuvent être avancés dans un domaine et pas dans l'autre

Christopher Di Bella : à réfléchir

Jean-Christiaan van Winkel : on ne veut pas discuter de pratiques de formatage. Notre plan est de tenir des rencontres lors des rencontre du WG21. Christopher Di Bella et moi espérons faire en sorte qu'au moins l'un d'entre nous soit présent à chaque rencontre. Nous souhaitons aussi tenir des téléconférences mensuelles, et faire en sorte que nos recommandations évoluent avec le langage

Jean-Christiaan van Winkel : il existe trop de petits programmes jetables et faciles à oublier. Nous souhaitons encourager quelque chose que les étudiantes et les étudiants pourront utiliser pendant longtemps

Jean-Christiaan van Winkel : comment se prépare-t-on à enseigner C++? On peut s'attader à la philosophie de C++ (en lisant D&E); on peut se tenir au courant des travaux du WG21... Nous pouvons les aider en construisant une liste de lectures suggérées, sans aller jusqu'à donner de recommandations fermes

Paul Preney : comment distinguer les bons des moins bons livres en fonction d'un style d'enseignement?

Jean-Christiaan van Winkel : nous essaierons de les aider à démarrer

Ben Saks : à San Diego, j'ai compris que les gens ne voulaient pas « identifier des gagnants » (bons et mauvais profs; bons et mauvais livres). Ce serait désastreux

Christopher Di Bella : je suis d'accord; pointer du doigt est contre-productif

Lita Lo : quand j'ai dû enseigner, la première chose que j'ai fait est trouver un bon livre

Jean-Christiaan van Winkel : on peut faire des recommandations indirectes, mais pas dire des trucs comme « voici un volume deux étoiles », « voici un volume quatre étoiles »

Lita Lo : nous pouvons mettre en valeur des groupes de livres qui ont été utilisés avec succès pour enseigner C++

Christopher Di Bella : ça pourrait être étrange de recommander un livre qui ne respecte pas nos règles

Lita Lo : on ne veut pas lire tous les livres

Attila Fehér : https://accu.org/ fait une liste de revues de livres, c'est très bien

Andrew Lumsdaine : il faut être prudents, pour ne pas que les gens aillent vers les mauvais livres

Andrew Lumsdaine : les professeurs sont paresseux. On peut les aider en recommandant des volumes

Frank ? : je suis d'accord avec Jean-Christiaan van Winkel. Recommander avec prudence seulement; nous parlons pour le comité, alors endosser un volume...

Patrice Roy : ... surtout s'il est écrit par un membre du comité!

Bob Steagall : il y a un guide sur StackOverflow vers lequel on pourrait orienter les gens

Patrice Roy : ça me rend très inconfortable

Christopher Di Bella : j'ai préparé une image docker avec un système de build utilisant CMake, des scripts de configuration, quelques compilateurs, un éditeur et des instructions. L'idée est de proposer un environnement de travail de base pleinement fonctionnel. Étant sur docker, ça facilite les mises à jour

Stephan ? : on ne recommande pas des volumes, mais on recommande un écosystème? Ça me semble contradictoire

Lita Lo : je suis inconfortable aussi

Paul Preney : je préfèrerais un guide, des instructions à des outils ou à un environnement spécifique

Bob Steagall : recommander un volume apporte des bénéfices pécuniaires à un individu; un compilateur, c'est différent

Jean-Christiaan van Winkel : il y a plusieurs compilateurs

Isabella Muerte : j'ai étudié dans un collège communautaire, sans sysadmin. Si j'avais eu un environnement docker, ça m'aurait beaucoup aidé. J'ai fini par apprendre surtout par moi-même. Je pense que SG15 et SG20 devraient envisager une TR commune qui serait par la suite tenue à jour

Paul Preney : en même temps, certaines écoles ne peuvent utiliser docket. Un dépôt avec des instructions serait plus utile

Christopher Di Bella : je comprends que plusieurs personnes sont autodidactes et sont dans des environments sans sysadmin. Un guide pour produire un écosystème n'est pas la même chose que promettre le véritable écosystème

Ben Saks : je pense que nous devons êtres conscientes et conscients que C++ sera souvent enseigné avec un objectif précis, par exemple pour fins de programmation système, et non pas pour lui-même. On enseignera souvent plus que le seul langage, ce qui implique de enjeus de Tooling. Une list liste de ressourcs pour aider les gens à choisir et à combiner des outils me paraît plus fécond

Stephan ? : concevoir un écosystème avec un compilateur amène les gens à apprendre dans cet environnement. Il y a des avantages pécuniaires rattachés à cela. Je ne dis pas que c'est mal : un pourrait recommander des livres et des outils

Attila Fehér : il faut à la fois couvrir les besoins des autodidactes et des étudiant(e)s. Peut-être faudrait-il deux sortes de listes

Jean-Christiaan van Winkel : on veut une liste de ressources avec lesquelles il est possible d'apprendre C++, en général

Frank ? : les échanges sur les outils m'intéressent, mais ce serait triste que cela gruge du temps sur la discussion qui devait porter sur l'enseignement

Jean-Christiaan van Winkel : en élaborant un curriculum, nous voulons des objectifs d'études (des compétences), en particulier des ASSBAT (A Student Should Be Able To...) ce qui devrait s'exprimer par des verbes d'actions

Paul Preney s'offre pour aider. Il ajoute que dans son pays, les enseignant(e)s ont accès à des guides comprenant des verbes recommandés

Trbea ? : il serait utile d'avoir quelques exemples de compétences de base (de pré-requis) pour être capables de visualiser les compétences de fin de formation

Stephan ? : j'aimerais des objectifs d'apprentissage test-driven, qui identifieraient ce qu'une étudiante ou un étudiant devrait être capable de faire en fin de formation

Paul Preney : de tels documents ont leur place, c'est normal, mais il est trop tôt pour les élaborr

Christopher Di Bella : on en reparlera

Jean-Christiaan van Winkel : dans quel ordre devrait-on aborder les sujets? Par quoi devrions-nous commencer? J'ai moi-même été coupable de choisir un ordre discutable, mais à ma décharge, j'ai enseigné C++ avant l'avènement de la STL. Nous souhaitons guider l'enseignement des éléments clés de C++ dans le bon ordre

Paul Preney : le bon ordre dépend du bagage des étudiant(e)s

Attila Fehér : je préférerais « ordre efficace » à « bon ordre »

Frank ? : il y a encore des gens qui pensent que C++ n'a pas de tableau de taille dynamique...

Isabella Muerte : j'ai appris C++ en écrivant un système de Build. Quelle mauvaise idée. Plusieurs apprennent avec Programming is Terrible de TEF (Thomas Edward Figg)

Paul Preney dit que la pratique de l'enseignement dépend de l'audience : enseigner à des étudiant(e)s de mathématiques et enseigner à des élèves du secondaire, ça apporte des enjeux différents

Jean-Christiaan van Winkel : on sait ce qu'on veut accomplir et ce qu'on ne veut pas accomplir

P1372

Christopher Di Bella présente la table de Gor Nishanov qui présente un comparatif entre niveau de complexité et taille de la population touchée

Jean-Christiaan van Winkel : ceci nous permet de visualiser à qui nous nous adressons. Nous pourrions recommander à WG21 de développer la pratique d'intégrer de telles tables aux propositions

Christopher Di Bella : devrions-nous écrire une proposition en ce sens?

Attila Fehér : une courte proposition

Paul Preney : ça nous donne un domaine d'application; on pourrait en profiter pour faciliter le triage et offrir le contenu adéquat

Ben Saks : je pense que WG21 devrait en tenir compte, et que nous devrions encourager cette pratique. Il faut éviter de développer une forme de vision tunnel, par contre : quand nous nous occupons de la complexité, la vie des gens en bénéficie

Attila Fehér : ça met en relief les choses qui sont experts-only

Christopher Di Bella : ça peut aussi aider les enseignant(e)s : this is for experts, maybe it should not be in my beginners C++ course

Trbea ? : une propostion sera faite pour toutes et pour tous. Je pense qu'il serait sage d'identifier clairement les prérequis

Jean-Christiaan van Winkel : selon moi, c'est un nice-to-have, pas un must-have

Stephan ? : j'ai eu vent qu'il y aurait un quality guidelines sur isocpp.org pour les propositions. On pourrait y ajouter cette règle suggérée

Jean-Christiaan van Winkel : qui écrira une proposition en ce sens?

Christopher Di Bella : je le ferai avec mon co-auteur Jean-Christiaan van Winkel. J'aimerais que Trbea et Stephan nous aident

P1279 std::breakpoint

Isabella Muerte : je souhaite ajouter std::breakpoint pour suspendre l'exécution de la machine abstraite. Je pense que ce serait un atout pour le développement logiciel, en particulier pour l'apprentissage. Ça aiderait à pallier la syntaxe étrange d'outils comme gdb

Isabella Muerte : s'il n'y a pas de débogueur attaché à un processus, cette fonction (qui serait dans <utility>) ne ferait rien

Isabella Muerte : la fonction pourrait être implémentée dans un contrat, mais ça manquerait de flexibilité; je préfère ne pas coupler les deux. Aussi, cette proposition n'interagit pas avec l'API de stack trace pour le moment, et n'utilise pas la même information (elle poursuite en survolent la brève terminologie, qui détonne de ce que la machine abstraite peut faire présentement)

Jean-Christiaan van Winkel : c'est la première proposition amenée à l'attention de SG20 >applaudissements!<. Peux-tu ajouter une table?

Isabella Muerte : bien sûr

Attila Fehér : ceci est présenté comme un mécanisme pour débutant(e)s, mais ça risque de nous présenter du code machine. C'est utile pour un novice, mais c'est pas un beginner feature (Isabella Muerte relate une expérience personnelle avec un autre langage)

Trbea ? : qu'est-ce que la fonction retournera? Isabella Muerte : rien. Son travail est de donner le contrôle au débogueur.

Patrice Roy : cela signifie-t-il qu'il faut modifier les sources et recompiler pour ajouter ou enlever un point d'arrêt?

Isabella Muerte : apprendre à utiliser un débogueur est une plus grosse perte de temps que réinstrumenter le code entre les exécutions

Isabella Muerte dit souhaiter une rétroaction générale, pas spécifique

Jean-Christiaan van Winkel : je souhaite votre avis sur la valeur de cette fonctionnalité dans un contexte pédagogique

Paul Preney : j'aime l'idée, mais pour fins éducatives, je pense qu'il faudrait identifier les points d'arrêt avec un texte donnant le contexte d'arrêt. Je m'attends à ce que les étudiant(e)s aient plusieurs points d'arrêt. Je m'attends aussi à ce que les appels à std::breakpoint() restent là longtemps; les transformer en no-ops à la compilation serait utile

Christopher Di Bella : l'audience pour ceci est EWG

Olga Arkhipova : ça ne me semble pas être un mécanisme pour débutant(e)s. Devoir attacher un débogueur complique l'apprentissage

Lita Lo : en pratique, j'aime arrêter le programme, puis attacher un débiogueur. Ce serait utile pour moi

Trbea ? : il y a des limites à la magie des IDE. J'aime cette proposition

Jean-Christiaan van Winkel souhait un vote. Isabella Muerte montre un exemple d'implémentation.

Frank ? : sur quoi vote-t-on?

Jean-Christiaan van Winkel : ceci améliore-t-il l'éducation?

Arthur O'Dwyer : est-ce que nous reconnaissons le problème ou est-ce que nous pensons que c'est la bonne solution?

Christopher Di Bella : le libellé serait We encourage Isabella Muerte to explore this proposal further

Le vote est pris, puis la pause débute àh 47

La pause est courte. J'en profite pour aller chercher un café et dire bonjour à Arthur O'Dwyer.

Nous reprenons le travail vers 10 h 11

P1389R0 Standing Document for educating novices-to-C++

Christopher Di Bella : le document commence par définir ce qu'on entend par beginner. On ne vise pas des néophytes absolus, mais on vise des gens qui connaissent pour ou pas C++

Ben Saks : il faudra des guides différents pour chaque famille d'étudiant(e)s

Paul Preney : ça ne rejoint pas ma définition de débutant(e)

Christopher Di Bella : on entend débutant(e)s avec C++

Paul Preney : je vais suivre; on débattra des termes une autre fois

Christopher Di Bella : idéalement sur la liste d'envoi

Stephan ? : il y a une liste dans le document, avec des stades (stade 1, stade 2, stade 3...). Ça me semble trop large

Jean-Christiaan van Winkel : on a envisagé viser toutes / tous les débutant(e)s, incluant les novices absolu(e)s, et on a choisi de ne pas aller là

Paul Preney : entendons vos idées d'abord; on discutera de compétences à atteindre éventuellement

Trbea ? : pourrait-on indiquer des aptitudes mesurables comme point de départ, par exemple « sait écrire une fonction »? Avec des autodidactes comme pour des enseignant(e)s, ça aiderait à polariser les efforts

Christopher Di Bella : j'aimerais intégrer cette idée à une version ultérieure de cette proposition

Bjarne Stroustrup : le terme beginner est précieux. Il y a beginner to programming et novice to C++, parfois un peu des deux, mais s'ils débutent avec C++, elles / ils ont probablement des conceptions erronnées de choses comme des boucles for

Paul Preney : j'aimerais que nos propositions débutent par quelque chose de la forme for the purpose of this paper, a beginner is...

Christopher Di Bella : pour moi, enseigner C++ est une tâche non-triviale. Enseigner aux débutantes, c'est un peu offrir une première impression du langage, et on veut donner une bonne première impression. Il y a trop de matériel sur le marché qui ne donne justement pas une bonne première impression

Andrew Lumsdaine : nos étudiant(e)s aujourd'hui utilisent des ordinateurs depuis des années, et on des attentes. Pour elles et pour eux, un ordinateur est multimédia, multitâches... et nous leur montrons à afficher du texte sur une console. Leur réalité devrait influencer ce que nous enseignons, et comment nous le faisons

Jean-Christiaan van Winkel : je me souviens d'un auteur qui a écrit un livre avec des cygnes sur la couverture et qui s'est donné la peine d'utiliser un environnement graphique...

Paul Preney : selon la définition sur la table, ils connaissent probablement C ou Java. Ça nous épargne un peu d'enseignement de syntaxe, mais il me semble utile de leur en monrrer assez pour ne pas qu'elles ou qu'ils retombent dans les pièges du passé

Paul Preney : il y a plusieurs manières d'ordonnancer les notions dans l'apprentissage de C++

Christopher Di Bella : je suis d'accord : ne vous attendez pas à utiliser new partout et à penser que c'est une saine pratique

Bjarne Stroustrup : je suis d'accord avec l'auteur du livre avec des cygnes sur la couverture  (Bjarne Stroustrup relate une anecdote où le Tooling bloquait l'apprentissage). Une différence fondamentale entre de totaux débutants et celles / ceux qui viennent d'un autre langage est que dans la deuxième famille, il y a plus à désapprendre

Bjarne Stroustrup : pour plusieurs, taper une commande au clavier est une première!

Graham Lopez: les étudiant(e)s ont des attentes, mais cela confond des enjeux du marketing de C++ avec des enjeux d'apprentissage de C++. Il n'y a pas de mal à apprendre les bases d'abord; personne ne penserait jouer du Chopin après quelques leçons de piano

Andrew Lumsdaine : le marketing compte (il suit avec une anecdote). Python laisse les étudiant(e)s faire des trucs chouettes dès le début

Frank ? : où en sommes nous dans cette discussion?

Jean-Christiaan van Winkel : j'ai entendu « ne nous concentrons pas trop sur le terme beginner; regroupons les clientèles »

Frank ? : j'ai entendu you can drive a car without being a mechanic

Bjarne Stroustrup : l'idée d'une unité : une conférence, une vidéo... Les unités d'apprentissage peuvent se composer, et ça peut fonctionner à la fois pour des débutant(e)s et des expert(e)s de diverses catégories

Christopher Di Bella : on y reviendra. J'utiliserais topic là où Bjarne Stroustrup utilisait unit, mais ça montre surtout qu'il nous manque un vocabulaire commun. On a essayé d'identifier des sujets pour débutant(e)s, et de les grouper en stades. Je les ai présentés en ordre alphabétique

Stephan ? : je pense que la chose à faire est d'aborder les sujets en unité aussi isolées que possible, et d'avoir divers curriculums pour guider les enseignant(e)s. Je pense que notre rôle est d'identifier ces sujet atomiques et ces chemins

Jean-Christiaan van Winkel : on ne prépare pas un curriculum, on propose des orientations

Stephan ? : on n'a pas à proposer un curriculum. On peut proposer des unités composables pour construire des curriculums

Paul Preney : avant que l'on ne mélange / brasse ces sujets, j'aimerais entendre pourquoi ils sont groupés comme ils le sont dans le document

Christopher Di Bella : avons-nous le temps?

Patrice Roy : ce que je vois dans le document, c'est des mécanismes. Les idiomes de C++ sont plus importants encore : types valeurs, RAII... Ça peut être dans une autre liste, mais c'est essentiel

Trbea ? : voulons-nous parler de pratiques de documentation, par exemple en utilisant la bibliothèque standard? Je n'ai pas vu ceci dans mes cours

Christopher Di Bella : c'est un peu comme préparer un environnement; tout le monde suppose que les autres savent comment faire

Attila Fehér : nous devrions avoir en tête les professionnel(le)s qui souhaitent migrer vers le C++ moderne. Ces gens ne retourneront pas à l'école, et nous voulons les rejoindre

Christopher Di Bella présente quelques-unes de ses diapos...

Mike Spertus : je pense qu'on est à la première étape, et la deuxième sera un gros désappointement en passant à la ligne de commande. Ma fille a écrit un jeu avec PyGame dès son premier cours

Bjarne Stroustrup : j'utilise souvent des images pour identifier les gens qui font les choses

Attila Fehér : C++ est un langage vaste. Les gens confondent complexité et quantité; on n'a pas besoin de tout savoir

Paul Preney explique comment il essaie d'enseigner C++ sans noyer les gens dans les détails

Christopher Di Bella poursuit. Il suggère de commencer avec un petit nombre de types primitifs, puis d'ajouter vector et les énumérations fortes

Ben Saks : ne pas trop en montrer tout de suite est très bien... si on peut s'en sortir indemne. Nous avons plusieurs audiences, et certaines sont faites de professionnel(le)s cherchant à aborder du code existant

Christopher Di Bella : mes diapos visent des débutant(e)s, en effet

Paul Preney : pour moi, la classe est un environnement où il faut réduire le bruit. Le cours est un voyage. On veut amener tout le monde à destination. Le texte dont nous discutions est justement le point de départ d'une discussion

Arthur O'Dwyer : à propos de la liste de types, je vois ça comme trois pots : un pour ce qu'elles / ils doivent savoir, un autre pour ce qu'elles / ils n'ont pas besoin de savoir, et un troisième plein de trucs amusants pour les rassurer... après leur avoir révélé l'existence de https://en.cppreference.com/w/

Bjarne Stroustrup : je me sens aussi de https://en.cppreference.com/w/ pour celles et ceux qui veulent en savoir plus. Ça permet d'éviter d'autres sources de moindre qualité.

Bjarne Stroustrup : nous devons leur montrer une forme de réalité. Elles / ils apprendront des trucs étranges, des pointeurs, mais nous n'avons pas à leur montrer ça tout de suite. Donnons-leur du C++ relativement moderne pour démarrer, puis quand ce sera opportun, nous pourrons y aller de « maintenant, si nous n'avons pas accès à ceci, que pouvons-nous faire? »

Attila Fehér : une aptitude-clé des programmeuses et des programmeurs C++ est savoir qu'il y a une machine derrière le code. En parlons-nous aux débutant(e)s?

Bjarne Stroustrup : si elles / ils ont eu un cours sur l'architecture matérielle, on peut leur montrer comment le langage modélise la machine. Avec des débutant(e)s, une « version bébé » suffit. Utilisez des images, des schémas

Jean-Christiaan van Winkel : quelle est l'histoire derrière ce document? Christopher Di Bella essaie d'expliquer avec des diapos mais se fait interrompre sans arrêts

Christopher Di Bella : il est sage de réfléchir à un contenu unifié (Christopher Di Bella poursuit sa présentation, en recommandant d'enseigner en vue d'un objectif)

Nevin Lieber n'est pas convaincu pas un cas d'utilisation de références

Christopher Di Bella dit être à la recherche d'un bon point de départ

Bjarne Stroustrup suggère de parler de ref-vers-const, par exemple sur un gros objet comme une matrice . Il est d'avis qu'une débutante / un débutant comprend la taille, mais comprend moins l'utilisabilité (il insiste sur l'importance de connaître le profil de nos étudiant(e)s)

Paul Preney : faiut commencer par les notions et suivre avec la syntaxe; le chemin inverse est plus ardu

Bjarne Stroustrup : il importe d'expliquer le « pourquoi »

Christopher Di Bella : le « pourquoi » est l'un des plus beaux aspects de l'enseignement

Bjarne Stroustrup : c'est une différence entre enseignement et entraînement

Jean-Christiaan van Winkel : prenons une pause; retour à 13 h sur le modèle suisse (donc : à temps!)

La pause débute à 11 h 25

Souper du lundi

Je sors manger avec Anna Dusíková, Jeff Snyder, Vincent Reverdy et un autre ami dont le nom m'échappe. Ils veulent des ramen et ont trouvé un resto hors de la zone touristique, à 20+ minutes de marche.

Il fait chaud. J'ai vu :

Heureusement, c'est simple, bon, pas cher, Mon bol :

Je profite du repas pour m'enquérir de leur perception de l'enseignement de C++. Je ne suis pas content de ce que j'entends. Ils viennent de quatre pays distincts (Angleterre, France, É.-U., République Tchèque), mais dans les quatre cas, ils sont autodidactes et ont rencontré des profs parresseux; quand ils ont vu C++, c'est en tant que C avec un peu plus... quand il reste du temps à la fin de la session.

Souper du lundi

On sort. Je prends une photo du Hawaï non-touristique, et je vous l'offre.

Je fais de la marche rapide pour revenir, car je suis le scribe de la rencontre.

Comme nous débutons les travaux, une enseignante d'une école secondaire locale (qui enseigne Java) arrive avec une dizaine d'élèves, moitié-moité garçons et filles. Nous les accueillons

Nos travaux débutent à 13 h 10

Jean-Christiaan van Winkel rappelle à toutes et à tous l'importance de la concision, et invite à laisser Christopher Di Bella terminer sa présentation

Christopher Di Bella revient sur la différente entre utiliser C++ et utiliser des mécanismes de C++, convenant que le langage ne se limite pas à une liste de mécanismes. Il fait remarquer que sa liste inclut des mécanismes de C++ 20 (ou qui sont susceptibles d'y être C++ 20) comme les intervalles (ranges), les modules ou les contracts. Il dit savoir que sa position sur constexpr est controversée, mais aimerait ne pas en débattre aujourd'hui.

Christopher Di Bella : le stade 2 porterait sur l'utilisation des mécanismes, en particulier les bibliothèques : comment en profiter, comment mesurer les résultats. Ma position sur la portée est controversée. Le stage 3 porterait sur l'allocation dynamique de mémoire, les sum types, RAII, tuple, la programmation générique... Le stade 4 porterait sur l'interopérabilité avec C, avec du vieux code C++, et sur le recours aux conteneurs associatifs

Jean-Christiaan van Winkel : au stade 3, RAII me semble un peu tardif

Christopher Di Bella : ça va avec la gestion des ressources

Paul Preney : sur la base de la définition de beginner proposée, les stades me semblent trop vastes. Je comprends que c'est un premier jet. Quand j'enseigne à des beginners qui connaissent la programmation,m je commence avec la bibliothèque standard : elle permet de programmer sans être une experte ou un expert de structures de données

Christopher Di Bella : placerais-tu les algorithmes et les conteneurs au stade 1?

Paul Preney : pour ce groupe? Oui

Trbea ? : la portée est au stade 2 mais je ne comprends pas pourquoi. Aussi, quand j'ai appris à programmer, je pensais en pseudocode; montrer aux gens qu'il existe de vastes bibliothèques de code validé et testé (la bibliothèque standard!) est une bonne chose.

Trbea ? : je ne suis pas sûre que des stades soient sensés; des paquetages seraient peut-être plus raisonnables

Christopher Di Bella : je suis d'accord pour la bibliothèque; mon texte était un compromis. On peut aussi aborder la bibliothèque par stades

Stephan ? : parles-tu de la bibliothèque standard ou de bibliothèques tierces?

Christopher Di Bella : au stade: bibliothèques tierces

Trbea ? : et la portée?

Christopher Di Bella : portée au stade 1 et durée de vie au stade 2?

Trbea ? : ça aiderait à comprendre les messages d'erreurs. Organiser les notions en paquetages serait utile si ceux-ci sont petits. Certains des sujets listés ici sont vastes

Stephan ? : les stades me semblent suggérer un aprentissage linéaire. Je ne suis pas d'accord. Il y a plusieurs points de départ, et plusieurs objectifs d'apprentissage. Le préfère les notions atomiques, j'aimerais qu'on en fasse une liste aussi exhaustive que possible, et encourager la construction de curriculums sur cette base

Christopher Di Bella : peut-on identifier des notions atomiques et les grouper en paquetages?

Stephan ? : peut-être. Je n'aime pas l'apprentissage linéraire

Trbea ? : les deux vont dans la même direction

Ben Saks : je pense qu'on devrait insister sur les compétences à développer. Ce que je vois dans le document occupe beaucoup plus qu'un seul cours.

(Christopher Di Bella est surpris)

Ben Saks : il nous faut aussi clarifier le degré d'atteinte des compétences

Jean-Christiaan van Winkel : j'ai entendu Paul Preney parler d'aborder l'héritage virtuel tôt... Quoi? Mais je comprends que ça dépend des gens dans la salle. Être débutant est relatif

Patrice Roy : il y a beaucoup plus qu'un seul cours ici, du moins si on veut que les étudiant(e)s comprennent quelque chose. On veut des chemins : objectif, point de départ, les a priori, ce qui doit être montré. De ça, identifier les activités

Bob Steagall : apprendre est un processus itératif. Je n'apprends pas de manière linéaire, j'apprends par étapes. On avance et on recule...

Ben Saks et Paul Preney discutent du sens du mot virtual. Ben Saks : communiquer est difficule

Paul Preney : je planifie écrire une liste de termes, de mots. On peut se concentrer sur l'écriture de lignes directrice et sur les interdépendances et les prérequis. Je ne couvrirais jamais tout ce qui est ici dans un seul cours

Jean-Christiaan van Winkel : on parlait de méconceptions. J'enseignais UNIX, les gens venaient dans ma classe avec un bagage VMS ou DOS... Il nous faudrait un document en ce sens

Patrice Roy offre de l'écrire, du moins pour les gens qui ont un bagage Java ou C# (à partir de ce qui est sur https://isocpp.org/)

Mike Spertus est ouvert, tant que le ton utilisé n'est pas offensant

Andrew Lumsdaine : on doit distinguer cours sur C++ et cours utilisant C++. Plusieurs insistent sur l'enseignement de notions, puis se chamaillent sur le langage, mais les langages influencent les cours comme les cours influencent les langages

Christopher Di Bella : ce document ne touche pas à CS1 (programmation 101) car il y a abondance de littérature sur ce sujet

Stephan ? : si c'était mon document, j'en retirerais,  les stades. J'éviterais d'avoir une séquence enchâssée. Ensuite, j'essaierais de rendre les notions atomiques, puis de voir ce qu'elles contiennent... Peut-être dans un autre document

Olga Arkhipova : je ne vois pas les stades comme une ligne directrice. Pourquoi ne pas faire une Gor Table par notion (beginner / intermediate / expert pour chacune)? Par exemple, les templates peuvent être subtils à écrire, mais sont faciles à utiliser. Ceci permettrait de choisir et de combiner en fonction du niveau visé pour l'étudiant(e)

Mike Spertus : ce serait utile d'avoir un diagramme de dépendances pour les notions. Il m'est arrivé récemment de donner un devoir sans penser à montrer les requis pour le réaliser

Mike Spertus : on ne devrait pas écrire un document disant aux gens comment enseigner, mais on pourrait leur dire to show this, it would be useful to show this and that first

Paul Preney partage ses trucs pour l'enseignement de la sémantique de mouvement

Jean-Christiaan van Winkel : que fait-on de ce document?

Trbea ? : nous utilisons Overleaf (LaTeX), qui ressemble à Google Drive et paraît bien. Nous pourrions l'utiliser pour partager le document...

Jean-Christiaan van Winkel : c'est un point technique, mais la question porte sur le futur du document

Paul Preney : j'aimerais faire ma propre version et l'amener ici pour fins de discussion et de fusion

Bob Steagall : peut-on faire une analogie avec les travaux sur une TS? On pourrait faire en sorte que le débat se déplace sur le contenu du document, pas sur le document lui-même

Christopher Di Bella : je viens bien avec des proposition rivales, mais je préférerais une collaboration (Christopher Di Bella mentionne l'histoire « riche » des exécuteurs)

Christopher Di Bella : je vois trois avenues :

Paul Preney : lançons nos idées, voyons ce que ça donne, et on gardera ce qui peut servir à une TR.

Paul Preney : tenir des téléconférences régulières est important, mais commencer avec une démarche plus dynamique me conviendrait plus. Aussi, il est important d'écrire nos idées pour ne pas les oublier

Stephan ? : je pense qu'un standing document est une bonne idée : avoir un document commun, et le modifier par voie de propositions

Christopher Di Bella : j'aime l'idée d'une TR. Je suis l'auteur de deux grosses propositions, et il est difficile de garder l'attention des gens dans de tels cas. Ce serait plus simple de référer à un seul document cohérent

Bob Steagall : je pense que ce processus sied aux groupes d'étude. Le produit final, une TR, serait un document de consensus, et les gens seront parfois très en accord avec lui, parfois moins. C'est probablement le mieux qu'on puisse faire

Stephan ? : je vais esayer d'écrire un modèle pour ce que seraient les notions, et de l'amener à Cologne

Christopher Di Bella : pas besoin d'attendre si longtemps. Tu peux l'envoyer sur la liste de diffusion pour fins de discussion

Christopher Di Bella : quelqu'un est-il opposé à l'idée de faire une TR?

Paul Preney : quel format devrions-nous utiliser?

Jean-Christiaan van Winkel : on ne veut pas de numéro ISO. On veut un standing document qu'on puisse mettre à jour à loisir

Paul Preney : je pense qu'un devrait interagir plus au préalable

Mike Spertus : je préfère le terme TR-like au terme TR. Évitons de nous empêtrer dans l'administratif

Intermediate programmers

Jean-Christiaan van Winkel : nous n'avons pas de document pour lancer la discussion. Comment devrions-nous procéder?

Paul Preney : je préféreras voir une série d'attentes et d'objectifs. L'audience détermine ce qui doit être fait, et on compose

Jean-Christiaan van Winkel : suggères-tu de fondre les trois documents (novice, intermédiaire, expert) et un seul?

Paul Preney : oui

Stephan ? : je ne vois pas d'utilité à avoir trois documents. On ne veut pas un do this, mais bien un hey, I'm teaching C++, I go from here to there, here's a possible path

Ben Saks : les objectifs (student outcomes) sont la clé selon moi. Le mot advanced tel qu'utilisé ici a un sens bien différent du mot advanced dans un environnement académique, où ça pourrait signifier « prêt pour le marché du travail »

Jean-Christiaan van Winkel : l'angle du document est celui du sujet. Par exemple : la métaprogrammation n'est pas un sujet pour débutants (il fait en suite un résumé de l'approche selon laquelle on fera un seul document de forme TR-like)

Paul Preney : je veux bien aider

C++ Standard Foundation Survey

Christopher Di Bella présente le sondage de 2018, et dit que Herb Sutter lui a offert de placer un petit nombre de questions propres à SG20 dans la prochaine version. Puisqu'un sondage destiné aux enseignant(e)s a déjà été mené, celui-ci porterait sur l'apprentissage de C++

Patrice Roy rappelle sont expérience (triste) du dîner où ses quatres convives étaient des autodidactes, et traçaient un portrait décevant de l'enseignement (ou pas) de C++ dans leurs pays respectifs

Ben Saks : comment rejoindre les bonnes personnes?

Jean-Christiaan van Winkel lit les questions envisagées

Ben Saks : nous devrions clarifier avec Herb Sutter ce qu'il souhaite avoir. S'il veux deux questions seulement, je pencherais pour how did you learn C++ et at what stage in your career

Trbea ? : il est important aussi de savoir en quelle année...

Olga Arkhipova : que souhaite-t-on apprendre de ce sondage? Quelle information souhaite-t-on en extraire?

Bob Steagall : si nous souhaitons des questions pour aider à former des curriculums, de quelle manière les questiosn suggérées nous aideraient-elles?

Ben Saks : souhaitons-nous être réactifs ou proactifs? On ne voit pas C++ être enseigné assez, ou on ne le voit pas bien enseigné?

Bob Steagall : on a peu de bande passante, alors il nous faut maximiser la densité de l'information

Vito Castellala : on voudra savoir quel est leur background, et ce qu'elles / ils ont fait par la suite

Paul Preney : il me semble prématuré de tenir un sondage sans même savoir quelle forme aura le standing document

Bob Steagall : une idée serat what has blocked you most from learning C++? et How would you fix this problem?

Stephan ? : je ne pense pas que placer des questions dans un sondage nous en dira plus que nous n'en savons déjà. Il faut que les questions aient un but précis

James ?: j'aime bien l'idée de leur demander ce qu'elles / ils ont trouvé le plus difficile

Bob Steagall : je ne suis pas intéressé à une liste de trucs difficiles en C++, je veux savoir ce qui a rendu l'apprentissage de C++ difficile. Il y a une différence

Patrice Roy : le simple acte de créer un objet sans écrire new bloque certaines personnes... Ce ne sont pas toujours les idées difficiles qui bloquent les gens; l'enseignement des bases compte

Paul Preney : on veut rejoindre les instructeurs dans les workshops. Il nous faut leur offrir des lignes directrices pour enseigner les bonnes choses. Il nous faudrait un ensemble de quasi-documents partagés pour démarrer le tout

Jean-Christiaan van Winkel : il nous faut un Wiki

Christopher Di Bella : action, noté

Ben Saks : cherche-t-on toujours à cibler des questions?

Jean-Christiaan van Winkel : je ne suis plus certain que ce soit ce qu'on veut

Christopher Di Bella : nous pouvons en informer Herb Sutter

Paul Preney : si nous tenons un sondage, j'aime les questions suggérées par Bob Steagall

Trbea ? : à quel point le sondage est-il obligatoire?

Jean-Christiaan van Winkel : j'ai l'impression qu'on s'ajouerait à un sondage existant de https://isocpp.org/

Trbea ? : on pourrait demander aux gens de nous écrire quelques mots...

Jean-Christiaan van Winkel : c'est un enjeu d'échelle; faudrait consommer tout ça

Bob Steagall : si c'est un sondage qui nous appartient, je me limiterais à 5-10 questions maximum et ce serait le C++ Foundation Educational Survey

Ben Saks : je n'ai pas vu le sondage précédent; j'aimerais savoir ce qui s'y trouvait, et comment ça devait être utilisé. Ça m'aiderait à déterminer si je veux m'y ajouter ou si je préfère un sondage distinct

Christopher Di Bella : prenons un vote : We want to survey the greater C++ community in 2019

Lita Lo : est-ce un mandat de Herb Sutter?

Jean-Christiaan van Winkel : le sondage va sortir; la question est de savoir si nous nous y ajoutons

(pas d'objection)

Jean-Christiaan van Winkel : voulons-nous un sondage qui serait spécifiquement pour nous?

Christopher Di Bella : propose un vote dont le libellé est We prefer the C++ Standards Foundation Survey to be dedicated to questions for SG20 - Education. Le vote se tient

Stephan ? : je ne vois pas l'intérêt. Si je n'ai pas de question à clarifier, je préfère ne pas en poser. Je déteste les sondages

Olga Arkhipova : on a mentionné un sondage annuel...

Christopher Di Bella : ... ça a commencé en 2018

Bob Steagall : je pense que nous avons un consensus pour un sondage court. L'objectif est à mes yeux de collecter l'information de manière à mieux organiser notre standing document. Sur cette base, nous pouvons formuler un petit ensemble de questions orthogonales. Nous en avons déjà eux, on peut en trouver trois autres

Arthur O'Dwyer : j'estime important d'avoir un objectif tangible, de détacher ceci d'un processus ISO. Il nous faut un objectif : better teaching C++. Ensuite, on trouvera les questions pour nous aider à écrire le document correspondant

Paul Preney : si nous pouvons avoir notre propre sondage, ce serait ma préférence; sinon, attachons-nous au sondage annuel. J'aime les questions de Bob Steagall

Jean-Christiaan van Winkel : nous allons contacter Herb Sutter et lui demander de nous donner un espace de 2-3 questions sur le sondage de https://isocpp.org/

La pause débute à 15 h

Je prends des nouvelles de Christopher Di Bella, dont c'est la première présence parmi nous. Il me dit avoir vécu l'expérience de CWG (intimidante, il faut l'avouer); je lui ai recommandé d'aller faire un tour chez EWG pour voir l'autre côté de la médaille (radicalement)

J'ai passé le reste de la pause à bavarder avec Bjarne Stroustrup. Je pense qu'il est plus optimiste pour C++ 20 qu'il ne l'était pour C++ 17.

Les travaux reprennent à 15 h 25

Resources for teachers

Trbea ? : quel est notre objectif?

Christopher Di Bella : des lignes directrices pour aider à valider qu'un cours permet à un(e) étudiant(e) de rencontrer ASSBAT? Des exercices de revue de code de la forme what does this code do? Des exercices comme ceux dans A Tour of C++ 2nd Edition?

Paul Preney : pour cette catégorie (exemples), je pense aux vieilles publicités de PCLint. Il y a plusieurs trucs subtils en C++

Paul Preney : il faut être prudent pour éviter les dérives et le plagiat

Stephan ? : on peut attacher les ressources aux notions, pour donner des indices sur leur enseignement adéquat. La question est de savoir comment, de quelle manière

Patrice Roy : la portée, l'ampleur de cet effort fait peur

Christopher Di Bella : c'est une préoccupation légitime. Stephan ?, ceci pourrait aussi être fait par un Wiki

Christopher Di Bella : selon moi, un Wiki sur Code reviews: what does this code do? avec une réponse possible pourrait aider à aiguiller les enseignant(e)s. Nous voulons éviter le plagiat en publiant toutes nos réponses en ligne

Ben Saks : je ne sais pas si placer ces ressources sur un média appartenant à SG20 est sage. Les enseignant(e)s ne partagent-elles / ils pas des documents?

Paul Preney : pas tou(te)s les enseignant(e)s, et typiquement en cercles fermés

Patrice Roy : il y a des enjeux de propriété intellectuelle

Jean-Christiaan van Winkel : j'envisage des catégories possibles de questions, p. ex. : here are suggestions if you're looking for non-copyable classes... Ou encore : suppose your colleague submitted this code, what comment would you give as a peer-review?

Isabella Muerte : personne ne peut empêcher le plagiat. Même si on essaie, il est toujours possible d'engager un tiers pour faire un devoir. Les outils comme Moodle ou Blackboard ont des bogues, et peuvent par exemple mal gérer les décalages horaires. On pourrait sonder les écoles pour savoir ce qu'elles font, quels sont leurs besoins. Plusieurs enseignant(e)s de collèges communautaires sont débordé(e)s, et les revues de code ne sont pas une pratique universelle

Patrice Roy : es-tu d'avis qu'on ne devrait pas encourager les revues de code?

Isabella Muerte : l'ingénierie logicielle et l'informatique se chevauchent

Paul Preney : les exemples doivent aider les enseignant(e)s à enseigner. Notre audience n'est pas les étudiant(e)s. On veut que les enseignant(e)s comprennent les notions qu'elles / qu'ils enseignent, et puissent s'inspirer de notre matériel

Isabella Muerte : je ne dis pas que les outils sont mauvais, juste qu'il ne vaut pas la peine d'essayer de les protéger

Paul Preney : le truc est de varier ses exercices

Christopher Di Bella : on souhaitait des exemples pour guider les enseignant(e)s, pas pour les rendre dépendants envers nous. Introduire une culture de revue de code est une chose importante

Olga Arkhipova : s'exercer à lire et à comprendre du code un peu mal foutu, développer un regard capable de détecter des antipatterns, ce sont des activités valables

Jean-Christiaan van Winkel : lire en comprendre des erreurs de compilation est aussi instructif

Isabella Muerte : tous les compilateurs semblent  adopter la pratique de Clang avec les messages d'erreurs. Maintenant, certains vont jusqu'à les encercler ou à pointer dessus tout en mentionnant les causes possibles

Jean-Christiaan van Winkel : à propos des revues de code, quand une entreprise engage une nouvelles programmeuse ou un nouveau programmeur, on donne rarement à cette personne la responsabilité d'écrire du nouveau code, du moins dans l'immédiat; il faut habituellement s'introduire dans la tête de ses prédécesseur(e)s et essayer de comprendre ce qui s'y passe. On pourrait construire une base de code qui a besoin d'amour, et la rendre disponible aux maisons d'éducation

Patrice Roy : les écoles en bénéficieraient; elles n'ont pas les ressources pour mettre ce type de structure en place

Trbea ? : qui sera en charge du Wiki?

Christopher Di Bella : moi

Jean-Christiaan van Winkel : on pourra demander à Herb Sutter pour un coup de pouce

Paul Preney : pourrait-on avoir une sorte de Gitlab pour partager des informations et des documents entre nous?

Jean-Christiaan van Winkel : à Google, c'est facile

Isabella Muerte : je recommande Gitlab. On peut s'y connecter à partir de Github. Sinon, Github offre un système de Wiki aussi

Bob Steagall : je suis disposé à créer un dépôt Github pour rendre service

Christopher Di Bella : j'ai créé une organisation SG20 sur Github, mais l'administration de WG21 a déterminé que nous devrions être intégré à la leur

Paul Preney : avoir un espace privé est un bon point de départ

Varia

Jean-Christiaan van Winkel : l'objectif est de se voir aux rencontres du WG21. Je ne pense pa être à Cologne, mais Christopher Di Bella y sera. Nous tiendrons des téléconférences approximativement mensulelles

Paul Preney : à quel rythme? Connaîtra-t-on les dates d'avances?

Jean-Christiaan van Winkel : ça tend à tomber lee vendredi à 8:00 PST pour maximiser la participation

Bob Steagall : a-t-on choisi le vendredi du mois?

Christopher Di Bella : pas encore

Bob Steagall : je suggère qu'on le fasse. Un message sur la liste de diffusion peut suffire

Jean-Christiaan van Winkel : merci Patrice Roy pour avoir pris les notes

Patrice Roy : attendez de les avoir lues!

Jean-Christiaan van Winkel : la rencontre fut-elle utile?

Semble que oui. On cesse les travaux vers 16 h

J'ai passé une bonne heure suite à la rencontre à éditer le Wiki de SG20 et à bavarder avec Bob Steagall. Par la suite, je me suis pris une salade, j'ai parlé brièvement avec ma belle Za, puis je suis retourné dans l'une des salles de bal pour assister à la présentation sur l'audio avec C++ offerte par Guy Somberg, Guy Davidson et Timur Doumler.

Guy Somberg, Guy Davidson, Timur Doumler (Roger Orr sert a titre de Chair)

RO : SG13 doit discuter de std::audio demain après-midi. On veut expliquer ce que c'est

Les présentateurs se présentent (!)

Timur Doumler : c'est une séance d'information seulement : état de l'audio en C++, ce que c'est, comment ça fonctionne, etc. On ne parlera pas de P1386R0 ce soir

Timur Doumler : il y a de l'audio partout maintenant (liste des appareils, des interfaces, des domaines d'application)

Timur Doumler : on peut faire de l'audio portable... avec '\a' (on fait des blagues sur les options ouvertes par les travaux de SG16 sur Unicode). Timur Doumler enchaîne sur les API commerciales, portables et propriétaires. Selon lui, plusieurs sont en C (ou en Java), or quand on est près du matériel, ils font tous à peu près la même chose. Toujours selon lui (et selon Guy Somberg), rien n'a vraiment changé depuis les années '90 à ce niveau (on a ensuite droit à un survol du fonctionnement du matériel, et le fait qu'en bout de ligne c'est des signaux; l'échantillonnage, le mixage, etc.)

JF Bastien demande ce qu'on fait avec les dénormalisations; Guy Somberg dit qu'on les élimine. JF Bastien demande comment : ajouter 3 puis enlever 3? Guy Somberg dit ne pas savoir. Timur Doumler parle de quelques techniques. Jeffrey Yasskin demande si les devices ont des noms, si oui dans quelle langue et comment on les gère. Guy Somberg répond. JF Bastien demande s'il y a un lien entre le device de sortie et le tampon qui sera utilisé. Plusieurs répondent

Timur Doumler présente les couches d'E/S audio côté User Space et côté Kernel Space, puis enchaîne sur les Callbacks audio. Il discute de la latence associée à un traitement par tampon. On a des questions sur le coût de manquer une trame ou un tampon. Je pense aux démos que mon ami David Viens fait parfois devant mes étudiant(e)s. Jeffrey Yasskin fait remarquer que ça parle de threads à haute priorité, que C++ ne supporte pas présentement. Gor Nishanov dit que Patrice Roy est sur ce dossier; Patrice Roy dit qu'il y revient au prochain meeting.

Timur Doumler fait une démo et montre le code qu'un client devrait écrire pour y arriver (du White Noise, une tonalité, ce genre de truc). Mike Spencer demande si Timur Doumler a essayé de jouer avec les coroutines au lieu des Callbacks; Timur Doumler dit qu'il a compris comment faire ce matin alors non (de plus, c'est le système d'exploitation qui le rappelle). Gor Nishanov dit que ça se fait bien avec des coroutines. Timur Doumler dit que les pratiques qu'il présente sont stables depuis une trentaine d'années. Plusieurs enchaînent sur des manières de profiter des coroutines. JF Bastien dit qu'il attend de le voir (de l'entendre) pour le croire

https://github.com/stdcpp-audio

Guy Somberg prend le relais pour expliquer comment on implémente des effets audios. Il explique le tout à haut niveau, incluant les changements de fréquence d'échantillonnage. Il enchaîne avec un exemple pour jouer un .WAV sans compression.

Jeffrey Yasskin : comment se fait la synchronisation quand tu thread souhaite être alimenté de données? Timur Doumler : pas avec un mutex. Peut-être une condition variable?

Guy Somberg présente le chemin d'un signal dans un graphe de DSP. Jon Kalb demande pourquoi additionner des signaux plutôt que faire des moyennes. Guy Somberg dit qu'en pratique, quand on fait des moyennes, on converge vers le silence. Les gens ne sont pas convaincus des mathématiques présentées ici; c'est pas une bonne foule pour tricher (même involontairement!) sur les maths. Hans Boehm : quelle est la latence tolérable avant d'entendre le problème? Timur Doumler : ça dépend du problème (il donne des exemples)

Timur Doumler : la présentation de demain utilisera du code simplifié car nous avons maintenant std::span et std::mdspan

On termine vers 20 h 34.

Le reste de la soirée a porté sur la mise à jour de la page que vous consultez présentement (ce n'étais pas fini quand je suis allé me coucher)...

Jour 4 22 février 2019

Debout àh 45, douche, courriels... La routine.

Je n'ai pas réussi à finir de formater mes prises de notes d'hier, alors je poursuis le tout ce matin; il y en avait vraiment beaucoup, et ayant été scribe pour SG20, mes notes sont en anglais et doivent être traduites.

Je passe chercher un café et de petites bouchées de Mauka (fuits séchés, noix de macadam, amandes, graiens de tournesol, noix de coco, oeufs, farine sans gluten, miel de Menehune). C'est bon, mais comme tout ici, c'est un peu cher.é En fait, tout coûte à peu près le double de ce que ça coûte à la maison.

Ce matin, pour moi, c'est SG14 dans la salle de bal numéro 4. C'est Michael Wong qui nous accueille ce matin, et on va parler d'algèbre linéaire.

Je suis scribe de la rencontre. Deux trucs généraux mais hors d'ordre qui ont accroché mon oreille :

Pour des raisons de temps, il est probable que je ne traduise pas ce qui suit. Il est tard est je suis fatigué.

Matrix Template Library – Andrew Lumsdaine

Questions / answers:

A proposal to add linear algebra support to the C++ standard library

Bob Steagall presenting:

Brève pause àh 48. JF Bastien nous donne l'endroit où la délégation canadienne se rencontrera pour déterminer nos positions nationales en vue des votes en plénière demain. Je bavarde un peu avec Roger Orr qui me raconte une manoeuvre semi-administrative faite chez CWG ce matin.

On reprend les travaux vers 10 h 11.

Questions / answers:

P1504R0: On vectors, tensors, matrices, and hypermatrice

Vincent Riverdy presenting

Souper du lundi

Nous avons fermé les livres un peu tard, soit à 11 h 35.

Comme bien des groupes, la délégation canadienne s'est réunie (au restaurant de poisson très agréable où j'ai mangé pour souper lundi et mardi) pour faire le point et prendre des positions sur les points les plus chauds. Pour des raisons évidentes, ces discussions sont à huis-clos.

Je sais que plusieurs, sachant que j'aime cuisiner, me demandent des rapports culinaires quand je vais en voyage. Ce midi, j'ai pris une bière rousse, qui accompagnait une assiette contenant une salade de chou maison (très correcte, sans être spectaculaire; crémeuse, pour celles et ceux qui se demandent) et deux tacos souples au poisson. On parle d'un poisson blanc, avec une salsa d'ananas à l'intérieur et une salsa verde piquante en option dans l'assiette. C'était très agréable.

J'ai pensé à celles et à ceux qui grognent et me demandent si je leur montrerai Hawaï à l'extérieur... Honnêtement, si on ne dînait pas, je ne verrais à peù près pas Hawaï (et en plus, cette semaine, il pleut tout le temps). Cependant, aujourd'hui, il fait soleil alors voici la vue devant le resto où j'ai dîné (il y a une rue entre le resto et la mer). Mon hôtel a une plage (mais je n'ai pas eu le temps d'y alller), et se trouve à droite, une marche de moins de trois minutes. C'est bien joli, donc, même si j'en profiterais plus si j'avais du temps... et si j'étais avec mon amoureux, faut bien l'avouer (sans toi, Za, c'est juste pas pareil; je t'aime)

Au retour, plusieurs options s'offrent à moi. J'ai décidé d'y aller de manière exploratoire chez SG19, un groupe que je connais moins, mais dont le sujet d'étude rejoint un peu mes travaux au doctorat.

Je serai scribe à nouveau.

Boost Graph Library (BGL)

Andrew Lumsdaine presenting :

Questions / answers:

P1415 SG19 Machine Learning Layered List

Michael Wong presenting:

On prend la pause vers 15 h

Pendant la pause, je croise Gor Nishanov qui semble avoir vécu un imbroglio le matin-même et cherche à éclaircir sa pensée pour envoyer un message (écrit) constructif. Je m'asseois un peu avec lui et un travaille la formulation. J'espere que ça va aider

Jens Maurer passe nous saluer. Il remarque qu'en ayant laissé une table et quelques chaises dans le hall, le tout se trouve à être utilisé de manière régulière. Il nous dit qu'il envisage en faire une pratique récurrente dans le futur, si l'espace s'y prête. Faut dire qu'ici, il n'y a pas vraiment de pause (il y en a, mais bon...) : ces moments servent à faire circuler l'information entre gens qui ont travaillé sur des dossiers différents, et servent à préparer / à retoucher des textes en vue de présentations.

Les travaux reprennent vers 15 h 25

Questions answers:

P1416 SG19 Linear Algebra for Data Science and Machine Learning

Michael Wong presenting:

Questions / answers:

Souper du lundi

On finit vers 16 h 10 (tout le monde est fatigué), mais j'ai pas mal de formatage à faire encore.

Truc amusant : à 17 h, tout le monde est encore là en train de parler technique alors que la rencontre est terminée depuis une heure!

Je suis allé me chercher une salade pour souper. Alors que je regardais ce que je mangerais, je suis tombé sur ceci (à droite), qui fera sans doute rire mes proches. Je vous laisse donc l'image à droite, sans ajouter de commentaires.


Alors que je me dirigeais vers ma chambre, j'ai croisé mon ami Billy Baker et son épouse Tishanda Baker. Les deux m'ont offert de les accompagner pour souper, et m'ont informé qu'il célébraient leur anniversaire de mariage; j'ai apporté ma salade à la chambre (ce sera mon déjeuner demain, tout simplement) et je suis allé les rejoindre.

Nous sommes allés au Kona Brewing Company, à quelques minutes de marche à peine. Il y avait une longue attente (45 minutes environ pour une place assise), mais nous avons décidé d'attendre (si vous regardez l'image au centre sur https://konabrewingco.com/come-visit sachez que juste en dessous, mes amis sont assis, et que je suis debout et c'est devant moi).

Souper du lundi

Nous avons d'ailleurs vu la charmante petite bestiole que vous pouvez contempler à droite. Aucune idée ce que c'est : c'est un lézard, je sais, et il devait faire 2-3 cm de long environ, mais je ne connais pas le nom de l'espèce. Remarquez les trois points rouges sur le dos, ça doit être distinctif je suppose.

Pendant que nous attendions, plusieurs autres du WG21 sont venus au même endroit. En particulier, car nous attendions en même temps, Nathan Sidwell et son épouse (très sympathique, mais dont je ne connais pas le nom). Nous avons bavardé des travaux de la semaine, mais aussi de la vie. L'épouse de Nathan est enseignante au secondaire en Nouvelle-Angleterre... en programmation. Elle fait un peu de robotique avec les adolescentes et les adolescents, de même que de l'alphabétisation quant aux ordinateurs et quant à Internet.

J'ai su que Tishanda a accompagné Billy à LEWG cet après-midi; elle est du monde médical, et ne programme pas, mais elle a entendu les discussions, s'est bien bidonnée : ça parlait de violation d'ODR, et elle a compris que c'était vilain; ça parlait aussi de Hidden Friends, en lien avec le mot-clé friend du langage, et de quelques autres trucs moins mémorables; elle a même participé aux débats, ayant suffisamment écouté les points de vue pour être capable de se former un jugement.

Nous avons pris une bière locale (quand même, elle était faite sur place), et un peu de pizza (très bonne). La mienne avait de l'ail (ce que l'on ne mange pas à la maison ces temps-ci, dû à la diète un peu restrictive de mon grand garçon Ludo), de la saucisse portugaise (idem : pas de saucisse à la maison depuis novembre 2018), du parmesan, du gorgonzola, des épinards... La croûte comprenait un peu de grains utilisés dans la conception de leur bière. C'était agréable, et côté prix c'était raisonnable.

Nous avons parlé de la vie, des enfants, de nos cheminements respectifs. Une soirée en compagnie très agréable.

En quittant (vers 20 h environ; j'avais encore du travail, et fut une grosse semaine pour Billy comme pour moi alors nous sommes un peu fatigués... et il reste la plénière demain!), Tishanda et moi avons pris une photo de l'extérieur du lieu où nous avons mangé. Évidemment, ma photo était merdique et floue, alors je vous présente les siennes (qu'elle a eu la gentillesse de me faire parvenir!) :

Le véritable plaisir, évidemment, était la compagnie. J'espère pouvoir les accueillir s'ils décident de passer un jour par Montréal.

Bon, cela dit, faut se préparer pour la plénière de demain...

Jour 5 23 février 2019

Lever àh 45 comme à l'habitude. Je me rase car après une semaine comme celle-ci, je suis de moins en moins présentable. À titre de déjeuner, je mange la salade prévue pour hier soir à l'origine, je parle un peu avec ma belle Za et mes plus jeunes Vayda et Ludo (je m'ennuie de vous!), puis c'est les préparatifs pour le check-out. Je prends la peine de remercier les gens de l'hôtel, qui ont été tout à fait charmants et pleins de petites attentions pour rendre le séjour plus agréable (p. ex. : j'avais des échantillons de dentifrice avec moi, à titre de dépannage, et les gens de l'entretien avaient remarqué et m'en laissaient un tout neuf chaque jour).

C'est ce matin que nous saurons officiellement quelle forme aura C++ 20 (les prochaines rencontres, à Cologne cet été et à Belfast cet automne, viseront principalement à le peaufiner, et à lancer les travaux vers C++ 23; c'est beaucoup de travail, et je suspecte qu'il y aura encore des bouleversements, mais le vote qui donnera la direction la plus claire se tient aujourd'hui). Il y a une belle fébrilité dans l'air.

On commence par faire le tour des groupes d'étude.

Hans Boehm : SG5 ne s'est pas rencontré

Chandler Carruth : SG7 après-midi complet. Nouveau modèle, ça avance. Remplacer offsetof par une non-macro

Lawrence Crowl : SG6 deux jours et demie. Beaucoup de trucs. Voir le Wiki

Roger Orr : SG13, soirée pour l'audio, après-midi pour l'audio (avec quelqu'un à distance par Zoom). Pas de progrès pour 2D Graphics

Gabriel Dos Reis : SG12, trois jours (deux avec WG23, sur MISRA, Michael Wong s'est occupé de ces deux jours, 75% fait pour les vulnérabilités de WG23, MISRA la prochaine fois). Ville Voutilainen demande s'il y aura un MISRA C++ en 2019. Michael Wong ne peut dire, mais on révise basé sur C++ 17. Gabriel Dos Reis : deux papiers vendredi : débordements arithmétiques (implementation-defined au lieu de comportement indéfini; une partie ira à SG6), et un nouveau modèle d'arithmétique sur les pointeurs (avec Hans Boehm et Paul McKenney, car la définition actuelle de l'invalidation des pointeurs ne fonctionne pas en situation de concurrence)

Michael Wong : SG14, rencontre en personne sur l'algèbre linéaire, séance de soirée aussi sur le même sujet. Andrew Lumsdaine a parlé de sa bibliothèque de calcul matriciel (la MTL : forces, faiblesses), Bob Steagall a parlé de l'approche par strates pour l'algèbre linéaire. Les rencontres en personne se poursuivent pour au moins les trois prochaines rencontres. Merci à Patrice Roy pour la prise de notes. Nous avons aussi eu une soirée sur Freestanding, et ces travaux se poursuivent.

Titus Winters : SG15 est sous la charge de Bryce Adlestein-Llebach maintenant. Bryce Adlestein-Llebach : nous avons parlé de l'interaction avec les modules, et pensons que ce sera notre principale préoccupation pour les prochaines années. Nous souhaitons écrire une TR sur les outils, compilateurs et systèmes de Build, et sur leur interaction avec les modules. Nous aurons des téléconférences mensuelles d'ici Cologne. Je veux remercier tou(te)s les participant(e)s. Je remercie Titus Winters pour tout ce qu'il a fait.

Tom Honermann : SG16 aura deux propositions pour vote ce matin dû à RHM (sur UTF-16 et UTF-32), et sur la concordance entre notre IS et celui décrivant Unicode. Nous avons eu une rencontre, et nous avons discuté des liens avec les expressions régulières, car celles qui sont standardisées ne supportent pas Unicode. Nous cherchons des volontaires avec l'expertise et la passion du sujet pour résoudre ce problème. Nous avons eu un très bon papier par Steve Downey, qui a mené à des discussiosn intéressantes, et Peter Bindels a eu la gentillesse de prendre les notes pour nous.

Hans Boehm : Michael Garland a géré SG1 en l'absence d'Olivier Giroux cette semaine mais a dû quitter. J'ai ses diapos. En gros : 23 propositions, environ 20 participants (moins pendant les échanges sur les coroutines), cinq jours de rencontres. Celles sur jthread et la dépréciation de volatile (pas de panique, c'est moins grave que ça en a l'air) s'en vont vers C++ 20. On quitte la concurrency TS et on fonce vers la concurrency TS v.2. On a parlé de clôtures asymétriques. On a parlé d'exécuteurs (cinq propositions, dont deux s'en vont vers LEWG). Plusieurs autres propositions (souvent des suivis de travaux en cours). Contactez-moi si vous voulez en savoir plus. Merci à Michael Garland pour avoir tenu le fort cette semaine.

JF Bastien : EWGI vise à aider EWG à avoir des propositions de meilleure qualité. Nous en avons vu 27 sur trois jours; quatre sont allés à EWG tels quels, trois ont essentiellement été arrêtés, et le autres ont eu une rétroaction pour les aider à avancer. On a eu entre 8 et 19 personnes selon les moments.

Bryce Adlestein-Llebach : LEWGI s'est rencontré environ 26 heures sur trois jours et demie. Nous avons examiné 43 propositions : 30 revues de direction, six revues de design, sept rétroactions sur designs hâtifs. Sept on été essentiellement arrêtés. Un a été envoyé à LEWG pour C++ 20, 11 pour C++ 23, un pour EWGI, sept vers des SG, et 16 ont besoin de revenir à LEWGI après un peu de travail. On a discuté d'audio, d'algèbre linéaire, de Freestanding, de std::uuid, de std::colony, de files concurrentes, de texte, etc. Nous étions nombreux (une vingtaine). Pablo Halpern demande si on doit nécessairement passer par LEWGI d'abord maintenant; Herb Sutter dit que EWGI et LEWGI sont des groupes d'études, techniquement; on peut aller directement à d'autres groupes si la rétroaction préliminaire n'est pas nécessaire. ATalbot : a-t-on une raison écrite pour chaque rejet? Bryce Adlestein-Llebach : oui, on prend soin d'interpréter les résultats des votes aussi, mais je n'arrive pas à le faire pendant la semaine, ça vient après (faute de temps).

Michael Wong : SG19 a tenu sa première rencontre en personne (ce groupe d'étude a été fondé à San Diego). Andrew Lumsdaine a présenté BGL. Nous avons donné une rétroaction aux gens qui travaillent sur l'algèbre linéaire sur une perspective de Machine Learning. Je m'attends à une bonne participation lors de nos rencontres en Europe. Nous tenons des téléconférences chaque mois.

Jean-Christiaan van Winkel : SG20 a tenu sa première rencontre en personne (ce groupe d'étude a été fondé à San Diego). Nous avions entre 15 et 25 personnes selon les moments, en plus d'une visite d'élèves du secondaire. Nous avons évalué une première proposition en lien avec l'éducation. Nous avons aussi célébré Gor Nishanov pour le premier usage d'une Gor Table (Jean-Christiaan van Winkel explique ce que c'est : une table qui décrit la population attendue en fonction du niveau de complexité d'un mécanisme). Nous avons débattu de notre Standing Paper, et décidé de changer le modèle initialement envisagé pour aller vers un graphe de dépendances par notions. Nous envisageons un document agile, TR-Like, avons des téléconférences mensuelles, et je veux remercier Patrice Roy pour la prise de notes malgré les débats.

Ville Voutilainen : EWG a discuté de de contrats : plusieur propositions pour changer les présupposés, une pour les enlever... Le statu quo demeure, mais nous avons renommé expects / ensures en pre / post. Quelque chose me dit que ces discussions ne sont pas terminées. Nous avons discuté de modules, et avons approuvé D1498 sur le Linkage interne, qui devrait régler les problèmes de Name Lookup qui avaient été découverts. Nous avons examiné plusieurs propositions pour les coroutines, et maintenons notre soutien envers la TS. EWG tient le même discours depuis des années, et souhaite intégrer les coroutines pour C++ 20. Nous avons approuvé des conteneurs constexpr (mais les allocations non-transitoires ne sont pas prêtes; on n'aura pas de vector<vector<string>> qui soit constexpr tout de suite). Les Expression Statements sont approuvées, les captures avec ... aussi. Nous avons raffiné <=> et son interaction avec ==. Capturer par référence des Structured Bindings est approuvé. Certaines initialisations triviales constexpr ont été ajoutées; la création implicite d'objets à bas niveau est acceptée (P0593; ça va permettre d'écrire... vector, mais sans comportement indéfini!), mais on va vouloir que LEWG jette un oeil à certains détails. Le mot-clé constinit a été approuvé P1143. On a accepté la dépréciation de volatile, un ajout de mouvements implicites, la déclaration using enum. Trucs particulier : on a approuvé l'initialisation avec parenthèses des agrégats. Un gros merci à CWG qui a fait des miracles. Et merci à Juan Alday pour la prise de notes.

Titus Winters : LEWG a vu 53 propositions (moins que les 64 de San Diego), ce qui en laisse 15 qui n'ont pas été couverts, faute de temps. Un a été priorités pour C++ 20. Avec LEWGI, ça fait 96 propositions. On s'est demandé comment marquer les constructeurs explicites, quelle est la portée de la Lakos Rule. Le formatage avec std::format() s'en va vers C++ 20, et a été intégré avec std::chrono. On a des Ranges, avec interactions avec string_view et span (CTAD a été très pratique). Quelques nouveaux intervalles et adaptateurs (il reste zip à intégrer, car il reste des enjeux à régler). On a des vues Move-Only, ce qui relaxe certaines règles pour ce qui est semi-régulier (Titus Winters recommande de réfléchir à ceci; ça a des conséquences profondes). Nous avons touché aux modules et à leur interaction avec la bibliothèque standard (Ville Voutilainen veut des détails; Titus Winters dit qu'on a réservé des noms comme std pour garder de l'espace pour développement futur, et qu'on va permettre des importations spécifiques pour des non-macros; Titus Winters ajoute que l'importation de macros qui changent le sens d'un contexte d'importation a été examiné, mais que c'est un enjeu pour EWG; enfin, Titus Winters dit que si on a des problèmes d'ODR aujourd'hui, on va trouver les modules compliqués à utiliser, mais que c'est pas un choc). Nous avons travaillé sur <=> et ça accroît ma confiance envers ce nouveau mécanisme, particulièrement son interaction avec les types existants et ses conséquences sur le design de nouveaux types; on a entre autres fait de strong_order un point de personnalisation. Nous avons plusieurs nouveaux types : source_location, flatset, unique_function (avec un autre nom), ostream_joiner, out_ptr, un remplacement pour strstream (qui est encore là toutefois) reposant sur un span, un joining thread avec join tokens. Enfin, plein de trucs mineurs (opérateurs monadiques pour optional, trucs sur char8_t, ajustements à chrono, ssize(), trucs sur les bits, etc.). Des trucs pour C++ 23 aussi. Détail : on suppose que les usagers ne déclareront pas d'amis dans la bibliothèque standard, et s'ils font ça, on ne peut rien pour eux. Certains trucs n'ont pas été faits, en particulier les Shadow Namespaces (intéressant, mais pas le temps). Merci à Jonathan Coe pour prendre des notes. Titus Winters dit que les débats sont civilisés, ouverts et harmonieux.

On arrive aux gros morceaux.

Mike Miller : CWG a passé la semaine à traiter des propositions pour C++ 20, l'échéance étant ce qu'elle est (pas de Issues Processing). On a prévu quatre téléconférences d'ici Cologne pour ça. On a quelques Issues pour vote ce matin, mais elles ont été traitées avant cette semaine. On a presque réussi à traiter notre backlog de propositions. J'offre mes excuses pour une proposition approuvée pour C++ 20; son absence sur la liste des votes ce matin est dûe à une erreur cléricale de ma part, et nous la voterons à Cologne (désolé Corentin Jabot). Le plus clair de notre temps cette semaine fut consacré aux modules (deux jours), et nous apportons cela pour vote ce matin. L'autre gros morceau était les NB-Comments sur la réflexivité. Une proposition majeure, examinée mais pas pour vote ce matin, est CTAD pour les alias templates; on l'aime mais on veut la travailler encore car c'est complexe. On vise Cologne. Une Issue Resolution qui peut surprendre et n'est pas pour vote ce matin (à réfléchir) est P2382 : un new avec un type tableau, la quantité de mémoire demandée peut dépasser la taille requise (pour mettre un Cookie), mais avec Placement New, c'est aussi permis de faire un truc du genre, ce qui peut surprendre (et c'est difficile de le rendre portable). La proposition est de retirer cet overhead possible de cette forme pointue de new.

John Spicer prend la parole, et on passe aux votes.

CWG Motions

Motion 1 -- Move to accept as Defect Reports all issues in P1358R0 (Core Language Working Group "ready" Issues for the February, 2019 (Kona) meeting) and apply the proposed resolutions to the C++ working paper.

Adopté.

Motion 2  -- Move to accept as Defect Reports all issues in P1359R0 (Core Language Working Group "tentatively ready" Issues for the February, 2019 (Kona) meeting) and apply the proposed resolutions to the C++ working paper.

Adopté.

Motion 3 -- Move to accept as a Defect Report and apply the changes in P1286R2 (Contra CWG DR1778) to the C++ working paper.

Aaron Ballman dit que SG12 l'a regardé, et il y a un cas où ceci peut surprendre si le code utilisait noexcept. Nous ne pensons pas que c'est un problème, mais nous voulons vous en informer.

Gabriel Dos Reis : nous ne pensons pas qu'il y a un problème avec C++ 20. Certaines sortes de codes pourraient mal transitionner, et on veut vous avertir.

Ville Voutilainen : EWG n'a pas examiné cette proposition cette semaine.

Gabriel Dos Reis : non, seulement dans des rencontres antérieures.

Adopté.

Motion 4 -- Move to apply the changes in P1091R3 (Extending structured bindings to be more like variable declarations) to the C++ working paper. [Note that this paper is modified by the next motion.]

Mike Miller : ces changements supposent qu'on ne peut pas capturer une Structured Binding par référence, ce que la prochaine proposition changera, mais c'est que les deux ont été livrées dans des rencontres différentes.

Adopté.

Motion 5 -- Move to apply the changes in P1381R1 (Reference capture of structured bindings) to the C++ working paper. [Note that this paper assumes that the preceding motion passes.]

Adopté

Motion 6 -- Move to apply the changes in P1041R4 (Make char16_t/char32_t string literals be UTF-16/32) to the C++ working paper.

Adopté.

Motion 7 -- Move to apply the changes in P1139R2 (Address wording issues related to ISO 10646) to the C++ working paper.

Adopté.

Motion 8 -- Move to apply the changes in P1323R2 (Contract postconditions and return type deduction) to the C++ working paper.

Adopté.

Motion 9 -- Move to apply the changes in P0960R3 (Allow initializing aggregates from a parenthesized list of values) to the C++ working paper.

Chandler Carruth : il y a eu un changement de design dû aux travaux de CWG, ce qui renverse deux votes consensuels chez EWG. EWG en a-t-il été informé?

Ville Voutilainen : non. On n'avait pas le temps de le regarder.

Herb Sutter : est-ce que EWG est à l'aise avec ces changements?

Ville Voutilainen : je ne suis pas sûr.

Herb Sutter : ce vote devrait-il être tenu?

Ville Voutilainen : je suis l'auteur de la proposition...

Herb Sutter : et en tant que Chair?

Ville Voutilainen : ... oui

Nicolai Josuttis : je veux des explications

Ville Voutilainen : le changement portait sur le traitement des parenthèses comme un constructeur, mais cela menait à un ordre d'évaluation indéterminé, et jouait avec l'ordre de construction des sous-objets

Chandler Carruth : je veux lire le sommaire des discussions sur le sujet dans EWG (il procède)

Mike Miller : il y a un peu plus d'histoire. Initialement, on demandait à ce que ( et ) fonctionne comme { et }. Ensuite, comme un constructeur. En le spécifiant, on a frappé un noeud. En pratique, les implémentations raisonnables pour un tel cas vont toutes y aller de gauche à droite. L'effet rejoint selon nous l'intention manifeste de EWG.

Ville Voutilainen : l'idée ici est de permettre d'utiliser des agrégats pour make_shared(), make_unique() et autres (avant, il fallait avoir un constructeur).

Herb Sutter : je comprends que CWG estimait que EWG n'avait pas à le revoir.

Mike Miller : en effet.

Adam Martin : si ça ne passe aujourd'hui, est-ce que ça peut passer pour C++ 20?

John Spicer : oui.

Herb Sutter explique les règles de votation.

Le vote se tient. Adopté.

Motion 10 -- Move to accept as a Defect Report and apply the changes in P1009R2 (Array size deduction in new-expressions) to the C++ working paper. [Note that this paper assumes that the preceding motion passes.]

Adopté.

Motion 11 -- Move to apply the changes in P1103R3 (Merging Modules) to the C++ working paper.

Alisdair Meredith : mon entreprise estime que C++ 23 serait un meilleur moment pour les modules. Nous pensons que l'expérience manque.

Ville Voutilainen : cette information n'a pas été apportée à EWG cette semaine.

Herb Sutter : est-ce basé sur une découverte durant la semaine

Alisdair Meredith : nous pensions que cette information serait plus appropriée pour le plénière

Herb Sutter : apporter une... surprise en plénière est mal vu, à moins d'avoir découvert un problème technique suite aux discussions (quelqu'un ajoute que les préoccupations sont en partie dans les propositions échangées en lien avec les travaux de SG15)

Ville Voutilainen : je répète que cette information n'a pas été apportée à EWG cette semaine. Mon commentaire n'était pas une question

John Spicer rappelle l'éthique dans de telles circonstances

Pablo Halpern : il y a eu un vote informel américain sur le sujet, cela dit

Tom Honermann : une proposition sur le sujet a été amenée à Albuquerque, mais n'y avait pas été traité (d'autres commentaires suivent)

Nicolai Josuttis : j'espère que ceci n'est pas un commentaire technique. Les modules sont utiles, on les veut. Nous pensons que l'état de TS n'aide pas à la progression du dossier. En même temps, on ne veut pas manquer de flexibilité et on veut que ça fonctionne.

(un imbroglio survient; on le gère)

Barry Hedquist : l'information qui m'a été donnée a circulé sur nos échanges nationaux. Herb Sutter en a été informé

Herb Sutter : cela dit, tout ce qui est discuté ce matin repose sur des propositions. Les échanges nationaux appartiennent aux nations.

Bryce Adlestein-Llebach : si nous votons non, pourra-t-on voter oui encore à Cologne? (Herb Sutter présente l'ordre du jour pour C++ 20 sur l'écran; on pourrait, mais c'est pas souhaitable)

Ville Voutilainen : côté temps, il nous reste un an, trois rencontres

J. Daniel Garcia : si on trouve un problème d'ici un an, on a encore des NB-Comments. On devrait fusionner et aller de l'avant.

Nicolai Josuttis : c'est trop gros pour Cologne, ça a trop de conséquences.

Corentin Jabot : c'est gros; si c'est brisé, on ne pourra pas le réparer. Je ne pense pas que le design est correct.

Daveed Vandevoorde : EWG se rencontre-t-il à Cologne? Ville Voutilainen : bien sûr, on est toujours ouverts.

Isabella Muerte : je ne pense pas qu'on pourra faire de changements d'ici Cologne. C'est pas une TR qu'on va le faire avancer maintenant.

David Herring : il y a eu deux changements dans le design des modules cette semaine (Internal Linkage, et Single-File). C'est des trucs indésirables, mais pas inimplémentables.

Vote. Adopté. Applaudissements pour Richard Smith, Gabriel Dos Reis, Nathan Sidwell. Poignée de mains entre Gabriel Dos Reis et Richard Smith. Herb Sutter parle de l'histoire remarquable de cet effort et de l'exemple de collaboration que cela représente. Daveed Vandevoorde dit que ça fait 15 ans que ça se travaille

Motion 12 -- Move to apply the changes in P1185R2 (<=> = ==) to the C++ working paper.

Matthias Stearn : un problème technique a été relevé lors d'une revue hier soir, et est amené en plénière. Herb Sutter : ceci a-t-il été apporté à l'attention de EWG? Ville Voutilainen : non. On peut traiter les Issues durant les trois prochaines rencontres.

Adopté

Walter Brown dit que le travail de design de <=> fait que ce sera l'un des meilleurs cas d'intégration à Core et à Library jamais vu. Il félicite Herb Sutter. Applaudissements.

Pause versh 50. Il y a eu de l'action, mais il y a de bonnes nouvelles.

J'ai profité de la pause pour échanger quelques banalités (gentilles) avec Lisa Lippincott et Marshall Clow, mais j'ai surtout eu l'occasion de parler avec mon ami Aaron Ballman qui était présent lors des discussions chez SG12 qui ont fait ressortir le changement de comportement qui a été amené à notre attention en plénière. Il m'a expliqué qu'auparavant, écrire un truc comme noexcept sur une fonction spéciale générique sur la base d'un type T, puis utiliser un T qui ne respectait pas ce noexcept par la suite menait à une erreur de compilation. Désormais, le code généré respectera les souhaits exprimés par les sources du programme, mais cela peut mener à une erreur à l'exécution (un terminate() lors d'une levée d'exception dans une fonction noexcept, typiquement). C'est limpide, c'est acceptable à mes yeux, mais c'est effectivement un glissement de sens.

On reprend vers 10 h 10.

John Spicer reprend le micro.

Reflection TS

Motion 13 -- Move to apply the changes in P1390R1 (Reflection TS NB comment resolutions: summary and rationale) to the Reflection TS working paper.

Adopté

Motion 14 -- Move to appoint a review committee composed of Axel Naumann, [...TBD...] to approve the correctness of the Technical Specification for C++ Extensions for Reflection 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.

Les TBD seront Hubert Tong, Roger Orr et Guy Davidson.

Herb Sutter explique le changement administratif : la TS était écrite par rapport au WD de C++ 20. ISO ne le permet pas car ce n'est pas publié. On a donc choisi de le re-baser sur la TS de concepts... qui était écrite sur C++ 14... donc faut écrire des trucs désormais invalides... qu'on arrangera de manière éditoriale

Adopté

Coroutines

Motion 15 -- Move to apply the changes in P0912R5 (Merge Coroutines TS into C++20 working draft) to the C++ working paper and incorporate all open issues against the TS into the core language issues list.

Vote. Adopté. Bravo Gor Nishanov! Ovation debout!

Herb Sutter rappelle qu'il y a des années de travail et beaucoup d'autres gens qui ont fait avancer ce dossier. Il rappelle aussi qu'on n'applaudit pas contre des propositions qui n'ont pas réussi, mais bien pour la convergence, la recherche, le progrès, et l'avancement du langage

LWG Motions

Marshall Clow : LWG a été occupé. On avait 56 propositions sur la table, on en a traité 33, on en amène 17 pour vote. Tristement (!), LEWG nous a amené plus de propositions que nous n'en avons traité (Ville Voutilainen : c'est pas la faute de Titus Winters; Marshall Clow : je le blâme quand même!). On tient des téléconférence aux deux semaines.

(Bjarne Stroustrup prend une photo panoramique; s'il nous la fait suivre, le mettrai un lien sur la page)

Titus Winters : pour les téléconférences, sachez qu'il n'y a pas de garantie que tout ce que LEWG relaie à LWG se rende à C++ 20. Il y a beaucoup de travail à faire. On fera de notre mieux pour prioriser.

Marshall Clow : je veux attirer l'attention sur polymorphic_value, flat_map, P1135 (synchro) et les non-owning references. Ce sont de grosses propositions, et il y a des retouches à faire, alors nous ne les voterons pas cette semaine.

Library Fundamentals

Motion 1 -- Move to apply the changes in P0052R10 (Generic Scope Guard and RAII Wrapper for the Standard Library) to the Library Fundamentals 3 working paper.

Marshall Clow : c'est un cas un peu spécial. Ce fut écrit à titre de correctif sur le WD, mais nous pensons que Library Fundamentals 3 est un meilleur véhicule (pour l'essentiel).

Herb Sutter : des détails? Est-ce essentiellement correct?

Marshall Clow : pas des grosses retouches, mais on a un cas particulier qui a un destructeur susceptible de lever une exception.

Adopté

Thomas Köppe dit que Library Fundamentals 3 va toutefois dépendre de comment les irritants de cette proposition seront résolues. Il se peut que ce document ne soit pas dans le Post-Kona Mailing.

Draft Standard

Motion 2 -- Move to apply to the C++ working paper the proposed resolutions of all of the issues in P1457R0 (C++ Standard Library Issues to be moved in Kona).

Adopté

Motion 3 -- Move to apply the changes in P0339R6 (polymorphic_allocator<> as a vocabulary type) to the C++ working paper.

Vote. Adopté

Motion 4 -- Move to apply the changes in P0340R3 (Making std::underlying_type SFINAE-friendly) to the C++ working paper.

Adopté

**Motion 5* -- Move to apply the changes in P1272R1 (Byteswapping for fun&&nuf) to the C++ working paper. (retirée, car CWG a encore du travail à faire dessus)

Motion 6 -- Move to apply the changes in P0738R2 (I Stream, You Stream, We All Stream for istream_iterator) to the C++ working paper.

Herb Sutter : je préfèrerais que les blagues soient dans les propositions mais pas dans le titre (ça complique l'archivage)

Adopté

Motion 7 -- Move to apply the changes in P1458R1 (Mandating the Standard Library: Clause 16 - Language support library) to the C++ working paper.

Marshall Clow explique que cette proposition (et les suivantes) sont des améliorations et des modernisations de la manière d'exprimer les clauses de la bibliothèque standard. Les clauses 17 (rien de spécial à faire) et 19 (immense, faut plus de temps) ne sont pas traitées aujourd'hui

Adopté

Motion 8 -- Move to apply the changes in P1459R1 (Mandating the Standard Library: Clause 18 - Diagnostics library) to the C++ working paper.

Adopté

Motion 9 -- Move to apply the changes in P1462R1 (Mandating the Standard Library: Clause 20 - Strings library) to the C++ working paper.

Adopté

Motion 10 -- Move to apply the changes in P1463R1 (Mandating the Standard Library: Clause 21 - Containers library) to the C++ working paper.

Adopté

Motion 11 -- Move to apply the changes in P1464R1 (Mandating the Standard Library: Clause 22 - Iterators library) to the C++ working paper.

Adopté

Motion 12 -- Move to accept as a Defect Report and apply the changes in P1164R1 (Make create_directory() Intuitive) to the C++ working paper.

David Herring : ceci fait un test dans l'appel que la majorité des usagers voudront, mais qui représente tout de même un appel système supplémentaire.

Vote. Adopté

Motion 13 -- Move to apply the changes in P0811R3 (Well-behaved interpolation for numbers and pointers) to the C++ working paper.

Adopté

Motion 14 -- Move to apply the changes in P1001R2 (Target Vectorization Policies from Parallelism V2 TS to C++20) to the C++ working paper.

Adopté

Motion 15 -- Move to apply the changes in P1227R2 (Signed ssize() functions, unsigned size() functions) to the C++ working paper.

Ville Voutilainen : j'aimerais que Marshall Clow explique

Marshall Clow : bien sûr. Ceci fait en sorte que span::size() retourne un ptrdiff_t.

Herb Sutter : je viens de réaliser que Ville Voutilainen réagissait à cause du nom de la proposition, qui ne mentionne pas span.

Vote. Adopté. Jon Kalb va être content!

Motion 16 -- Move to apply the changes in P1252R2 (Ranges Design Cleanup) to the C++ working paper.

Adopté

Motion 17 -- Move to apply the changes in P1024R3 (Usability Enhancements for std::span) to the C++ working paper.

Peter Sommerlad : y a-t-il des liens avec motion 15? Marshall Clow : oui. Peter Sommerlad : ça va affecter un peu de code existant. Christian Trott : si on adopte [,] dans le futur, ça règlera plusieurs de nos problèmes dans le monde du HPC.

Adopté

Motion 18 -- Move to apply the changes in P0920R2 (Precalculated hash values in lookup) to the C++ working paper.

Adopté

Motion 19 -- Move to apply the changes in P1357R1 (Traits for [Un]bounded Arrays) to the C++ working paper.

Adopté

Marshall Clow : dans mon rapport, j'ai oublié de remercier les nombreux scribes de mon groupe. Ces notes sont précieuses, et sont utilisées.

Pablo Halpern : dans le rapport de EWG, on a parlé du changement de noms dans les contrats. Que se fera-t-il maintenant?

Ville Voutilainen : une proposition sera faite, CWG le traitera, et ça deviendra une Core Motion

Direction Group

Howard Hinnant : il y a eu une rencontre, je n'ai rien à rapporter de particulier. Nous avons des téléconférences aux deux semaines. Nous avons un Standing Paper qui sera mis à jour à quelques reprises chaque année.


John Spicer : nous avons un vote PL22.16 à prendre pour C++ Extensions for Concurrency

Barry Hedquist : la motion est de la retirer. SG1 est d'accord (vote informel). Essentiellement, elle a joué son rôle, les éléments se répartissent dans C++ 20, C++ 23 et le futur (ce vote ne concerne que les américains)

Hubert Tong explique les conséquences d'un tel vote

Vote. Adopté


Herb Sutter aborde la question des prochaines rencontres.

Nicolai Josuttis présente celui à Cologne (Köln, juillet 2019) : ça semble très joli. Il mentionne que Mike Spertus, entre autres, a personnellement sponsorisé l'événement. La proposition détaillant les règles d'inscription est N4783. Si on y va, il est important que le signaler avant le 10 mai (Nicolai Josuttis a pris un risque financier personnel).

Roger Orr présente celui à Belfast (novembre 2019) : Roger Orr dit que ses contacts à Belfast sont surtout ceux qui font avancer ce dossier, mais idéalement il y aura d'autres sponsors. Nous sommes nombreux, N4782 est la proposition détaillant les règles d'inscription. Jonathan Caves peut nous amener faire une visite touristique.

Anna Dusíková présente celui de Prague (février 2020) : dans un an, les contrats seront signés la semaine prochaine. Avast sera le sponsor principal.

(les suivants seraient Bulgarie juin 2020, New York novembre 2020 – à déterminer – et Kona février 2021; Jens Maurer dit qu'on essaie d'éviter la St-Valentin si possible)

Herb Sutter : depuis l'avènement de la République Tchèque à cette rencontre, nous avons 13 pays représentés en tant que NB à WG21.

Nicolai Josuttis : Kona est joli, mais c'est compliqué de venir ici (30 heures de trajet pour lui). J'aimerais venir moins souvent

Herb Sutter : on y va aussi avec les hôtes et les coûts. Une des raisons pour venir ici est que ça ne nous coûte pas cher

Herb Sutter fait remarquer que les quatre prochaines rencontres seront en Europe

Ville Voutilainen : il m'est arrivé deux fois de me trouver dans une rencontre du comité le 24 juin... Les Finlandais ne travaillent pas ce jour-là (Bjarne Stroustrup : les Danois non-plus!)

Hal Finkel : quelques informations sur le mailing. Post-Kona sera le 11 mars. Pré-Cologne sera le 17 juin. Merci d'avoir essayé notre nouveau système. La première journée, je sais que tout le monde a eu le numéro P1600 >rires dans la salle!<

Hal Finkel : on travaille fort pour mettre en place un bon système de révision. Si vous avez un problème, écrivez-moi tout simplement.

Hal Finkel : je sais qu'il faut mettre un document pour avoir un numéro et que ça ne tient pas la route, mais en attendant : mettez un fichier, peu importe lequel, et remplacez-le par la suite.

Herb Sutter remercie Hal Finkel pour tout avoir changé.

(Jens Maurer valide que les projecteurs se rendront à Cologne, donc que nous avons des volontaires qui iront là-bas)

Ville Voutilainen : EWG tiendra une rencontre à 13 h.

Mike Miller : CWG fera du Issues Processing à 13 h.

Marshall Clow : LWG traite des propositions à 13 h.

Titus Winters : LEWG ne se rencontrera pas. Allez aider Marshall Clow à LWG.

Walter Brown lit son traditionnel mot de remerciement, toujours apprécié et bien amené.

John Spicer conclut en acceptant une motion d'ajournement. Une grosse semaine de travail se conclut.

On finit vers 11 h 30. Je bavarde un peu avec Adam Martin, de MongoDB, qui est familier avec le Québec et a un français plus que décent. Je passe serrer la main de mon ami Gor Nishanov, pour qui je suis extrêmement content. Par la suite, j'ai une conversation un peu plus longue avec Jon Kalb à propos de l'organisation de CppCon 2019, car il y a beaucoup de nouveau (nouvel endroit, nouvelle organisation).

Je vais me chercher un wrap au commerce et je me dirige vers la salle où CWG travaillera en début d'après-midi; ce sera plus amusant – et plus utile – que d'aller attendre 6-7 heures dans un aéroport sans Wi-Fi décent.

Mike Spertus est là alors on traite une de ses propositions

Filling holes in Class Template Argument Deduction

Je n'ai que suivi les discussions de manière périphérique, mais il y a un presque 80 minutes de travail et Matthias Stearn et Mike Spertus ont établi qu'ils travailleraient ensemble pour polir le modèle. On a des chances de l'avoir pour C++ 20.

Core Issues

On y va...

2388. Applicability of contract-attribute-specifiers

David Herring : il semble manquer un détail, tout simplement. Jens Maurer le prend.

Aaron Ballman : ça prétend qu'un contact-attribute-specifier n'est pas un attribute. Je ne suis pas convaincu.

Matthias Stearn : ça cause de la consternation. Faut dire qu'ils ne sont pas ignorables.

Aaron Ballman : C ajoute des annotations, et il est important qu'ils soient ignorables. Si on utilise des annotations non-ignorables, ça a des conséquences sur eux.

Hubert Tong : ce sera plus compliqué à rédiger qu'on pensait; le terme appertains-to reste à définir

2389. Agreement of deduced and explicitly-specified variable types

Ceci est-il bien formé?

struct S {
   static int i;
};
auto S::i = 23;

Mike Miller : il est clair que c'est interdit pour les fonctions, mais le standard ne parle pas des variables.

Roger Orr dit qu'il y a divergence d'implémentation

Patrice Roy suggère que ce serait une bonne idée de l'accepter

Mike Miller semble penser que oui aussi. On a le choix entre Ill-Formed, Well-Formed, et P1 pour le revoir. Il penche pour Well-Formed.

John Spicer dit que si on connaît le type, on ne devrait pas avoir à le répéter.

Hubert Tong dit auto i = /* des trucs qui sont dans le même fichier */;

Aaron Ballman demande s'il y a un problème d'ODR avec ça; la réponse est non.

Mike Miller : on y va pour P1

1859. UTF-16 in char16_t string literals

Hubert Tong fait remarquer que ceci est résolu par les votes de ce matin.

Mike Miller note.

2390. Is the argument of __has_cpp_attribute macro-expanded?

La (méchante!) question est de savoir si __has_cpp_attribute est influencé par les expansions de macros... Brrrr.... Et il y a divergence d'implémentation

Jens Maurer : un P1? (Ok)

2395. Parameters following a pack expansion

Le standard n'est pas clair sur ce qui suit, et il y a des divergences d'implémentation :

template<class ...Types> struct Tuple_ {
   template<Types ...T, int> int f() {
      return sizeof...(Types);
   }
};
int main() {
   Tuple_<char,int> a;
   int b = a.f<1, 2, 3>();
}

Hubert Tong pense qu'il est important de déférer les Pack Expansions.

David Herring pense que c'est une oeuvre diabolique

Mike Miller : le truc à l'intérieur a un sens... très difficile à figurer. Faudrait une proposition

2392. new-expression size check and constant evaluation

L'exemple est :

template<class T = void> constexpr int f() { T t; return 1; }
using _ = decltype(new int[f()]);

Hubert Tong : la personne qui a écrit celle-ci est confuse sur le sens donné par le contexte.

Jens Maurer pense que c'est plus subtil que ça. Hubert Tong en convient. On recule et on réfléchit... C'est extrêmement pervers. La question est : est-ce que f() est évaluée?

Cet exemple est un monstre, rien de moins.

On prend une pause vers 15 h 5. Je bavarde avec Paul Preney dont c'est la première expérience d'Issues Processing avec CWG. Il essaie de verbaliser le monstre qu'on vient de traiter et... après quelques essais... arrive au même constat que moi : c'est un monstre.

On recommence à 15 h 27.

On convient collectivement que le monstre rencontré avant la pause est un P1.

2393. Pseudo-destructors and object lifetime

Résolu par P0593R3 Implicit creation of objects for low-level object manipulation

2396. Lookup of names in complex conversion-type-ids

Faut réfléchir aux cas suivants :

struct A {
   struct B; 
   operator B B::*(); 
}; 
struct B; 
void f(A a) { a.operator B B::*(); }             // first B is A::B. what is second B? 
void g(A a) { a.operator decltype(B()) B::*(); } // what about the operand of decltype? 
void h(A a) { a.operator X<B>(); }               // what is B here? (for some X<T>)

Hubert Tong se souvient d'en avoir parlé en téléconférence. John Spicer pense que la réponse est ... non-évidente. P1.

2397. auto specifier for pointers and references to arrays

Hubert Tong fait remarquer que la grammaire interdit ce qui suit (même si c'est utile, et si plusieurs implémentations l'acceptent) :

int a[3];
auto (*p)[3] = &a;

Jens Maurer pense que ça devrait être permis, mais que le travail terminologique requis est lourd.

David Herring demande si auto(*p)[3] serait un paramètre légal pour une fonction, une fois le correctif apposé. Hubert Tong pense que oui.

Hubert Tong demande si on devrait accepter auto(*p)[] sans dimension. Aaron Ballman pense que oui.

P0.

2398. Template template parameter matching and deduction

Les règles de déduction ont changé ces dernières années :

template<class T, class U = T> class B { /* ... */ };
template<template<class> class P, class T> void f(P<T>);
  int main()  {
    f(B<int>());       // OK?
    f(B<int,float>()); // ill-formed, T deduced to int and float
}

Un autre exemple serait :

template<typename> struct match;
template<template<typename> class t,typename T>
   struct match<t<T> > { typedef int type; };      // #1

template<template<typename,typename> class t,typename T0,typename T1>
   struct match<t<T0,T1> > { typedef int type; };  // #2

template<typename,typename = void> struct other { };
   typedef match<other<void,void> >::type type;

Mike Miller dit P1.

2399. Unclear referent of "expression" in assignment-expression

C'est un cas de clarification de la terminologie pour tenir compte de changements récents. Mike Miller s'en occupe.

2400. Constexpr virtual functions and temporary objects

On nous présente cette bibitte :

struct A {
   constexpr virtual int f() const {
      return 1;
   }
};
struct B : A {
   constexpr virtual int f() const {
      return 2;
   }
};
constexpr B b{};
constexpr A&& ref = (B)b;
static_assert(ref.f() == 2, "");

Hubert Tong pense que la recommandation de correctif est correcte. Jens Maurer le fera. David Herring fait remarquer que ref mène sur une temporaire, mais pas celle qu'on pense (par voie de Litetime Extension)

2401. Array decay vs prohibition of subobject non-type arguments

Une autre bibitte :

template <const char *N> struct A { static const int val; };
template <const char *N> const int A<N>::val = 0;
static const char c[2] = "";
int main() {
   A<c> a;
   return A<c>::val;
} 

C'est un cas de décrépitude, mais il y a de la divergence d'implémentation.

Hubert Tong rappelle qu'on tend à faire converger les cas constants et non-constants. Permettre ceci nous éloignerait de cette tendance. À l'exécution, il y a une interconvertibilité, mais à la compilation il y a une équivalence symbolique.

On la reverra. P1.

2402. When is the restriction to a single c-char in a Unicode literal enforced?

Patrice Roy se demande quel est le problème. Hubert Tong parle d'une possibilité de comportement indéfini... dans le préprocesseur...

Hubert Tong pense qu'il nous faut un exemple de Token-Pasting si on va jouer dans ce truc : est-ce qu'un jeton généré par Token-Pasting mais malformé et jeté plutôt qu'utilisé pose problème?

Aaron Ballman pense qu'en C, c'est implementation-defined.

Hubert Tong pense que la phase de traitement dans laquelle ce problème surviendrait influencera la priorité.

Roger Orr pense que SG16 devrait être informé. Aaron Ballman pense que ce serait poli.

On ferme les livres vers 16 h 20.


Valid XHTML 1.0 Transitional

CSS Valide !