À propos de WG21, Kona 2019

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.

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 $U_ir_i$? 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 $attribute-specifier-seq_{opt}$ 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 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.

Titus Winters nous accueille en expliquant que Bryce Adelstein 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 Adelstein 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 Adelstein 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 Adelstein 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 Adelstein 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 Adelstein 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 Adelstein 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.

On commence peu après 8 h, 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.

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.

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> où 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 $1 \cdots n$ et a des cas pour $n > 0$). 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 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

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

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 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)

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

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.

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 $10\%$ 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 Adelstein 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.

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 vers 8 h 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 à 9 h 47

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 $10000 \times 10000$ . 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

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 2 : 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 :

• Des propositions en compétition
• Une proposition avec amendements
• Une proposition commune avec co-auteurs

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

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++ 2^nd 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

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.

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

• Andrew Lumsdaine a un outil qui se nomme Calypso (allo ma grande si tu lis ceci!)
• Andrew Lumsdaine pense que almost-equals est le mauvais modèle pour la comparaison de nombres à virgule flottante. Je me sers d'un truc semblable tous les jours, mais je ne sais pas si on parle du même contexte. Je vais essayer d'en savoir plus, car ça pique ma curiosité

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

• Andrew Lumsdaine provides history on his matrix library, his generic programming approach, the absence of actual matrices and vectors, and discusses performance
• Andrew Lumsdaine gives credit to a colleague of his (whose name I don't catch) for the idea of expressing the library with templates instead of a class hierarchy
• Back then, there was a patented small object optimization. Applying that technique led to significant performance improvements
• Michael Wong provides somme additional context to Andrew Lumsdaine (and Jeremy Siek)'s work on concepts
• Andrew Lumsdaine : abstraction adds to reusability, but sometimes also adds to pain and work for users
• Andrew Lumsdaine : a student of mine did a study and found a "sweet spot" between too little abstraction and too much abstraction
• Andrew Lumsdaine : retrospectively, starting from mathematical definitions is the wrong angle
• Christian Trott : why do you say that?
• Andrew Lumsdaine : they're not bad, they're the wrong place to start
• Andrew Lumsdaine shows a C++ Conjugate Gradient that maps one-to-one with math textbooks
• Andrew Lumsdaine : is vector a Hilbert space? You can add a few operators and you're essentially there... It can be expressed in a generic manner, but it's easy to use the wrong concept (the requirements can be incorrect)
• Christian Trott : what are you thought on using operators? It works with operator+(), but once we get to operator*() it becomes unclear
• Andrew Lumsdaine : remember that all this came before move semantics and mandatory RVO
• Andrew Lumsdaine : is vector<double> a LinearOperator? Well, kind of, if domain and range have the same dimension...
• Andrew Lumsdaine : for generic programming, start with algorithms. Need to be efficient. A generic library is a systematic organization of abstract and efficient software components based on concepts
• Andrew Lumsdaine : when teaching C++ today, one can start from C++ 11 and forget the rest. You can be efficient without playing with pointers
• Andrew Lumsdaine : in many cases today, computation is free when compared to the cost of data movement
• Andrew Lumsdaine : lots of people are doing the same thing (linear algebra) in slightly different ways

Questions / answers:

• Christian Trott : people say we need to standardize existing practice. I think we also need to update existing practice
• Andrew Lumsdaine : good question, it depends. Some of if has to do with context
• Christian Trott : if what we design here cannot be future-proof with respect to hierarchical architecture, I fear we'll be designing something of limited use to the community
• Mark Hoemmen : lors of us use floating point numbers. Guy Davidson has mentioned fixed point. Do you think we would need a different design?
• Andrew Lumsdaine : I don't think so. It's a layered design. There's also a cool compressed floating point representation
• Michael Wong : you said you're working on something new for parallel execution
• Andrew Lumsdaine : yes, it's in progress
• Vito Castellala : executors are in the pipeline
• Michael Wong : we want to be in tune with our times, and we want to do heterogeneous computing
• Christian Trott : we can use executors with nested, heterogeneous parallelism
• Andrew Lumsdaine : algorithms are different when doing things in parallel
• Michael Wong : we could extend the historical paper to cover the future, or do a separate paper

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

Bob Steagall presenting:

• Bob Steagall : in terms of regular users, we're trying to support ease of use, meaning expressiveness, and reasonable performance out of the box
• Bob Steagall : having overloaded operators that looks and feel like what they see in textbooks is a must-have for games programmers
• Bob Steagall : others users will want the best possible performance and will want to tweak everything to get maximum out of the hardware
• Bob Steagall : games programmers use lots of small matrices. They're the ideal users
• Bob Steagall : HPC user matrices are very large
• Vincent Riverdy : a part of the HPC commnity has tens of billions of small matrices, e.g. for general relativity
• Bob Steagall : we try to address these two "markets" based on our perception of their needs: an interface that's intuitive and usable, a set of reusable building blocks for the vocabulary types, as well as highly customizable facilities to allow optimization for specific problems on specific hardware
• Bob Steagall : we want to minimize boilerplate code required for customization
• Michael Wong : have you thought of using concepts?
• Bob Steagall : the point of the paper is to make sure the design makes sense from a high-level perspective. We're deferring constexpr and concepts, but it's on the radad
• Mark Hoemmen : there are nice models for pre-concepts concepts in existing library
• Michael Wong : constexpr, concepts, parallelization and heterogeneous are things to consider
• Bob Steagall : we try to define workable and correct definitions for the key ideas and operations expected from such a library
• Bob Steagall : we also offer a list of terms from computer science (but in the C++ sense) to avoid ambiguous interpretation
• Bob Steagall : en engine manages resources associated with a math object
• Bob Steagall : among other things, we use the term vector in the mathematical sense
• Mark Hoemmen : we hope to make vocabulary and concepts converge with what is being done with mdspan
• Bob Steagall : our target is C++ 23, and we progress iteratively
• Bob Steagall : we decided to delay tensor support to C++ 26, due to the scope of such an effort
• Christian Trott : I'd like to have a discussion on tensors later, as I'm not sure we should address this
• Vincent Riverdy : I have a presentation on this, later
• Bob Steagall : Guy Davidson and I are not sure we could complete such an undertaking for C++ 23
• Guy Somberg : for game developers, this library will be less useful without quaternions
• Guy Davidson : I agree, but we'll add it incrementally
• Andrew Lumsdaine : quaternions are otrhogonal to linear algebra
• Guy Davidson : I agree, and maths are underrepresented in the standard
• Guy Somberg : thank you, I was scared we were throwing them away
• Bob Steagall : we see quaternions and octonions as complementary types
• Michael Wong : should they be developed in parallel on in sequence?
• Bob Steagall : in parallel. I welcome a quaternion library; being rings, not fields, they will be a good test for the library
• Graham Lopez : I hoped for sequential development, to reuse the rest of the library
• Guy Davidson : this would slow down our progress
• Mark Hoemmen : when people develop tensor libraries, they reach for the BLAS
• Bob Steagall : we allow for parametric memory source management
• Bob Steagall : we also allow for parametric addressing model, using fancy pointers
• Christian Trott : do you have composable ownership semantics?
• Bob Steagall : yes
• (discussion ensues with respect to 1-based indexing vs 0-based indexing)
• Bob Steagall : if only for performance reasons, let's stick to 0-based

• Bob Steagall : we can envision expressions with mixed element types
• Bob Steagall explains how customization is expected to be done, e.g. to benefit from intrinsics or SIMD instructions
• Bob Steagall presents considerations with respect to constexpr in the library
• Bob Steagall suggests we skip section 6 first, seeing an example in section 7, then returning to section 6
• Bob Steagall presents a design based on layered traits for elements, promotion, arithmetic, operators...
• Christian Trott : a related property of this is that for parallel computation with executors, we might hit a case where objects don't agree on execution. One can specialize operator traits to decide what to do
• Bob Steagall illustrates the design using a multiplication of a fixed sized matrix of double with a dynamically resizable matrix of float
• Paul Preney : this shows how we could special-case matrices of specific dimensions
• Bob Steagall : yes, through partial specialization of names found in the std:: namespace
• Mark Hoemmen : it's an example of customization for special use-cases
• Paul Preney : engine promotion is just a metafunction, so engine promotion would be a somewhat trivial task?
• Bob Steagall explains the nuances between element_type and engine_type
• Bob Steagall : there's a strawman implementation in the Github repo
• Mark Hoemmen : since std::allocator returns raw pointers, there's no ownership attached. Matrices are owning
• Bob Steagall : engine types are owning. This is intended to be similar in design to standard containers, which will be clearer when we go back and look at the implementation
• Christian Trott : we need things more like containers, which is probably the right thing for small matrices, but not for huge matrices where view semantics are better
• Mark Hoemmen : I thing the customization points provided can deliver
• Bob Steagall : engine types can be owning or non-owning
• Patrice Roy recommends Bob Steagall reads the matrix_multiplication_traits expanded example aloud at conferences, like Michael Caisse did with his Standard Slam in the past
• Christian Trott : I agree with the conceptual components proposed. I'm not sure that the general design with engines and partial specializations (instead of concept customization points) are the right approach. It's not a fundamental issue, and all components shown for customizability are the right ones, the thing that remains to be seen is if we're doing it the right way
• Bob Steagall : the question is whether we cover the needs of 80% of our users out of the box
• Paul Preney : can you put in your own engine?
• Bob Steagall : yes, and in your own namespace. There's an example used for debugging purposes in the document
• Christian Trott : I don't think the current engines will suffice for 80% of the users. I need a fixed sized engine with an allocator but which doesn't own its memory. There are many orthogonal dimensions
• Bob Steagall : I will buy your argument, that's a very good idea
• Guy Davidson : we could add that with additional succession papers
• Andreas Weis : I agree that we should not standardize an engine that's not orthogonal enough. I think we should start with a small subset, assess what makes sense, and build from orthogonal parts
• Mark Hoemmen : no similarly designed matrix library exists
• Guy Davidson : Matt Godbolt follows this project and will integrate it in Compiler Explorer. It will become simple to test new engine types and such, and look at the generated assembly
• Guy Somberg : I'm in the 80%. How many in this room are too? (about half of the room)
• Patrice Roy : cool, we just found co-authors to add stuff to the library!
• Graham Lopez : should scalar types be first-class citizens?
• Mark Hoemmen : they are
• Graham Lopez : if I do scalar times matrix, can scalar compete? Are they equal citizens?
• Bob Steagall : interesting question. I need to think about it
• Paul Preney : I think it can be implemented
• Bob Steagall provides examples
• Guy Somberg : if I'm multiplying a matrix of T with a matrix of U, how does this get resolved? (Bob Steagall explains the traits manoeuver)
• Mark Hoemmen : we could use defaults, but it's tricky if we target heterogeneous computing. Maybe no defaults is better
• Bob Steagall : we have defaults in the paper, but I'm not sure they're the correct ones

Questions / answers:

• Mark Hoemmen : to me, since you're using the same names and words than other libraries, this feels like standardizing existing practice
• Bob Steagall : compiler and languages advances have really helped
• Bob Steagall : we've had guidance from LEWGI which will help us progress
• Bob Steagall : following feedback from Mark Hoemmen, Christian Trott and Graham Lopez, we're revisiting some parts of the design. In the R2 version of the paper, we'll have a single vector type with an orientation based on context
• Mark Hoemmen : inner product is more useful that outer product in terms of operations
• Bob Steagall : this will reduce the number of traits and overloads, as well as the number of ADL attack vectors
• Bob Steagall : the reference implementation on Github is for debugging purposes only
• Michael Wong : objection to encouraging further work? (none)
• Christian Trott : we should specify the scope of what we wanrt to see in C++ 23 in order to focus our efforts
• Michael Wong : we'll discuss in the next telecon on March 6

P1504R0: On vectors, tensors, matrices, and hypermatrice

Vincent Riverdy presenting

• Vincent Riverdy : this paper is a comment following a discussion in LEWGI on Monday
• Vincent Riverdy : I'm a physicist. This influence my choice of vocabulary
• Vincent Riverdy : LEWGI asked if it is necessary to have both a row_vector and a column_vector
• Vincent Riverdy : we need to get the first layer right, get the proper building block
• Vincent Riverdy : some terms are overloaded (e.g. vector)
• Vincent Riverdy discusses what a vector is, with different sets of axis. The mathematical structure is more than its representation
• Vincent Riverdy : identifying a vector to its coordinates is wrong and leads to inconsistencies
• Vincent Riverdy : a tensor is not a cube of numbers (same idea)
• Vincent Riverdy : this leads to problems with covariance, contravariance and such
• Vincent Riverdy : a matrix is not a rank-2 tensor, nor a geometric object. It's a rank-2 array of numbers
• Vincent Riverdy : if we define vector wrong, it will make the desing of a tensor library of top of it difficult
• Vincent Riverdy : we have more abstraction capabilities than C or Fortran, particularly with concepts. The only type we really need is a hypermatrix
• Vincent Riverdy : rank 0 hypermatrices are scalars, rank 1 are vectors, etc.
• Vincent Riverdy : standardization can be done in layers. Layer 0 is mdspan, layer 1 is mdspan + storage (what Bob Steagall called engine), layer 2 is a mathematical multidimensional array, layer 3 is a host of geometrical objects such as vectors and tensors
• Bob Steagall : I'm hearing that using the name vector imposes a geometrical meaning that it might be premature to apply (Vincent Riverdy explains)
• Vincent Riverdy : a vector does not reduce to its coordinates
• Bob Steagall : if we named things better, would we avoid this objection?
• Mark Hoemmen : should we change the dot-product?
• Vincent Riverdy : yes
• Bob Steagall : std::vector will still cause a naming problem. Also, layers 0 and 1 are where we're trying to go. I think our proposal suits these
• Vincent Riverdy : it's on layer 1
• Guy Davidson : we're on a linear algebra paper; we don't plan to move into higher abstractions
• Vincent Riverdy : yes, but if we use the name vector the way it's used right now, we won't be able to write a proper tensor library
• Graham Lopez : I think you're describing how tensor libraries have been written for years: most don't even define a coordinate system, such a thing can intervene if needed, you just need to add a transform. Thus, I'm not sure why we need this thing, and if we do, their proposal is customizable enough
• Vincent Riverdy : for users that deal with several coordinate systems, being able to inject a coordinate system will be necessary
• Vincent Riverdy suggests names to finish his presentation
• Bob Steagall : the primary flaw you see is our use of the name vector. This will bring conceptual impedence mismatch later
• Graham Lopez : I'd argue the opposite. We should use the names that appear in existing practice. I do physics, people use the word vector
• Stephan ? : it's not new terminology
• Graham Lopez : it's established terminology
• Vincent Riverdy : naming things improperly breaks invariants

Je serai scribe à nouveau.

Boost Graph Library (BGL)

Andrew Lumsdaine presenting :

• Andrew Lumsdaine : I think one should start with what one wants to do
• Andrew Lumsdaine : with the BGL, we sought to decouple the algorithms from the data structure, but with a different traversal interface and access abstraction
• Andrew Lumsdaine : a graph is a pair(V,E) with V a finite vertex set and E a binary relation on V (e.g. and edge set). Edges are directed
• Andrew Lumsdaine : we put forward a property map, to do such things as weight, colors, distance, predecessor...
• Andrew Lumsdaine : there are interior and exterior (passed as argument) property maps
• Andrew Lumsdaine : properties set-up in a property map are accessed through operator[]
• Andrew Lumsdaine : visitors behave like STL functors that perform multi-callbacks. It makes for a poor person's aspect-oriented programming
• Andrew Lumsdaine : there's a lot of overhead in our implementation, and the barrier to entry was quite high
• Paul Preney : I've met users that considered using the BGL, but setting the property map seemed too complex to them
• Andrew Lumsdaine : I understand
• Andrew Lumsdaine : I've tried to think it over since C++ 11 arrived. I've arrived to the point where I think... there are no graphs. And there are thus no graph algorithms
• Andrew Lumsdaine gives some examples of algorithms and possible representations in C++ code
• Andrew Lumsdaine : intuition: if one can dereference the elements of a vertex and index into the original container, one has a graph. Thus, one could express a graph concept as a container of container with the property that the elements of the inner container can be used indirectly as indices to the outer container
• Andrew Lumsdaine adds a few other small requirements

Questions / answers:

• Dong Ping Zhang : what's your view of Vincent Riverdy's proposal?
• Andrew Lumsdaine : it's a matter of how we derive what are the concepts or data structures. There are many pathways. I'm advocating we start from algorithms, then categorize the abstractions. We'll probably end up with similar results
• Vincent Riverdy : I like the "there is no graph" idea, but I'm wondering if the number of algorithms we can run on data influences this perspective. Organization of data impacts efficiency
• Andrew Lumsdaine : I know my "there is no graph" position is a bit extreme, but it lets us write simple generic algorithms with less constraints
• Mark Hoemmen : do you feel like introducing executors and fine-grained parallelism will influence your design?
• Andrew Lumsdaine : I think it can be adapted well to hierarchical executors given the two-level traversal structure of the loop
• Mark Hoemmen : are we correctly modelling executors?
• Andrew Lumsdaine : I need more experience with them
• Vito Castellala and Michael Garland trade experiences with executor-based approaches
• Andrew Lumsdaine : introducing concurrency directly impacts the model, if only for synchronization
• Michael Garland: this kind of pattern is broadly applicable to more than graphs. My favorite way or writing mesh processing resembles this, and writing functional code makes things easier
• Vincent Riverdy : in the BGL, where did most of the complexity come from?
• Andrew Lumsdaine : the property maps. Also, the visitors
• Michael Garland: you used breadth-first search in your examples. Have you thought about adaptative traversals?
• Andrew Lumsdaine : the strategy I'm describing would adapt, I think
• Michael Garland discusses strategies where one pushes or pulls a conceptual barrier
• Andrew Lumsdaine is unsure, Vito Castellala proposes an approach

P1415 SG19 Machine Learning Layered List

Michael Wong presenting:

• Michael Wong : we've tried to prepare a layered list of features, similar to what SG14 does with linear algebra
• Michael Wong : we've had a presentation this morning, and they already have a skeleton implementation
• Michael Wong lists feature requirements for machine learning as seen from that layered approach (see the document for the complete list)
• Michael Garland : I would imagine we want something on layer 0 on precision, or on quantization
• Michael Garland : with respect to linear algebra, there is a desire for accumulation in a precision different from the precision of the elements
• Robert Simpson : I hear people wanting to apply algorithms that change quite often
• Robert Simpson : one can have a whole graph representing a neural net, and one can compile the whole thing in a single binary (companies might be converging on the latter). It's a question of whether the final thing will be a graph of kernels or a single binary
• Vincent Riverdy : on layer 0, one could build a workflow of computations similar to what tensorflow does
• Dong Ping Zhang : what's the rationale behind the layers?
• Michael Wong : start with something simple, constrained by the work that can be done, to build more complex things
• Dong Ping Zhang : in layer 1, I see things that seem simpler
• Michael Wong : they might be moved to layer 0
• Michael Wong : layer 1 targets better information and data interchange packages
• Michael Wong : display could leverage the efforts of SG13
• Mark Hoemmen : we haven't talked a lot about inter-language interoperability, particularly to move 2D arrays back and forth
• Michael Wong : we need plain interoperability with Python
• Patrice Roy : Boost has Boost.Python
• Michael Wong : C++ has expression templates out of the box
• Michael Wong : supporting accelerator dispatch to inference engines and heterogeneous devices is needed. Current efforts involve executors
• Patrice Roy : in that sense, SG14 and SG19 have the same objectives and needs
• Michael Wong : I spoke with Chris Lattner and he told me he's building a graph extraction pass for Swift that could be used for C++ too
• Vincent Riverdy : what graph are we talking about?
• Michael Wong : computation graph
• Michael Garland : one thing that's difficult to do is robust automatic differentiation. Python does that well
• Vincent Riverdy : could reflection help?
• Michael Garland : it's hard to say for the moment
• Michael Wong : my guess is we'd still need to make some effort
• Vincent Riverdy : could it be done through expression templates?
• Michael Garland : we have forward mode that works, but the backward mode is more interesting
• Michael Wong : layer 2 requires packaging and dependency management (SG15 efforts), as well as integration with external libraries and tools
• Michael Wong : what's the difference between floating point precision handling and quantization? (Dong Ping Zhang explains)
• Robert Simpson : sometimes, you need continuous quantization while training your network
• Robert Simpson : it's often not critical to get defined precision, as long as you have the same precision (cites MPEG encoding)
• Michael Wong : These exchange formats; need we do anything to support them? Onyx and ANDF (?). They take a training set of weights, and store them, so they can be brought over to the inference engine and reproduced. Onyx is an agreement between Microsoft, Amazon, and Facebook; ANDF is a Chronos thing. More [use? of] Onyx. Hardware inference engine.
• Robert Simpson : I'm not that familiar with Onyx; it looks like a language. Not sure what it means for C++ for support that. It's an exchange format, very dynamic. Onyx seems to be changing very rapidly at the moment.
• Michael Wong : Trying to get my head around what it means to support that. What does it mean to support
• Robert Simpson : you can compile down to SYCL or C++. If we standardize (I missed some subtelty). A kernel has no idea where it's going to go
• Vincent Riverdy : if you have something to walk through the computation graph in C++, and if we have an algorithm to walk through that graph...
• Robert Simpson : you'll need a converter from one representation to another
• Mark Hoemmen : are people wary of licensing the GNU Scientific Library? It worries us (it's GPL)
• Michael Wong : it can be something else with similar functionality
• Michael Wong : we need differentiation, interpolation and such for scientific computing. What do you use?
• Lita Lo : we don't use that GSL
• Vincent Riverdy : some GSL algorithms are ...
• Vito Castellala : in my group, we either use something we know or roll out our own
• Graham Lopez : in the long term, there's desire to make improvements
• Lita Lo : the API is very C-like
• Damien: it's a C library. We'll need something else
• Patrice Roy : ask SG6?
• Vincent Riverdy : I'll be the liaison
• Patrice Roy : noted
• Michael Wong : we need interfacing to machine learning / data analysis libraries. Most are ten years old
• Michael Wong : we also need to integrate with a growing list of compilation platforms
• Andrew Lumsdaine : there's a lot of activity on that side
• Michael Wong : it holds promise but looks experimental to me
• Michael Garland : explains what tensor-rt is, and how it differs from tvm
• Michael Wong : there's also glow, which is an IR acting on kernel fusion at the LLVM-IR level. It's a semi-compilation system
• Michael Wong : there are many levels of specialized tooling in there. Most people would use parts of each; these are complex, specialized tools. Using a higher-level language tool like CUDA or C++ is another option. One could also build from various libraries such as Eigen
• Patrice Roy : what's the goal of this document?
• Michael Wong : getting a feel for the proposed layering, and prioritizing
• Patrice Roy : to me, all this sounds like a call to arms. There's a lot to do!
• Michael Wong : absolutely
• Robert Simpson : what's it about Python libraries that make them so useful for machine learning?
• Lita Lo : you don't need to recompile, so you can try many things easily
• Robert Simpson : we're not competing against Python, then
• Michael Wong : that's not the goal
• Patrice Roy : for huge amounts of data, C++ is less of a factor, and ease of experimentation counts more. What we could do is have a faster compile-run cycle
• Michael Wong : Jupyter might be an option

On prend la pause vers 15 h

Les travaux reprennent vers 15 h 25

• Michael Wong : let's get to layer 3, which is a far-away goal, but includes data visualization tools, ways to debug machine learning algorithms, tools to experiment with reinforcement learning, support for artificial neural networks and deep learning
• Michael Wong : I think we can do layer 0, a part of layer 1 in 3-4 years, a bit of layer 2 in 4-6 years
• Lita Lo : develop or adopt?
• Michael Wong : develop. Maybe in the form of a specification. It's like linear algebra
• Bob Steagall : our proposal is a foundation upon which to build
• Michael Wong : we can't make data scientists move to C++, but we can make C++ more attractive for data scientists. I chair the SYCL group, and SYCL is pure C++. I make one better, I help the other

Questions answers:

• Vincent Riverdy : interoperability with other things, such as Python, various formats... This could be put in a separate category. This seems very specific, and does not touch ISO standards
• Michael Wong : interoperability to other languages or to other ISO languages?
• Michael Wong : let's take the Boost.Python library. We could standardize that
• Michael Wong : in practice, we could make a deal with other groups or companies in ordre for them to stabilize their low-level interfaces

P1416 SG19 Linear Algebra for Data Science and Machine Learning

Michael Wong presenting:

• Michael Wong presents slides
• Michael Wong : it's all about processing data
• Michael Wong : a model training is often optimizing a cost function (often a variation of gradient descent, thus linear solving)
• Michael Wong : model training is 20% of the time, the rest is processing data. We need something usable and readable
• Vincent Riverdy : most of the time or most of the development time?
• Michael Wong : I think we're talking about development time (agreement in the room)
• Michael Wong : the reference is Python / NumPy
• Michael Wong : tools are multidimensional arrays (3D, 4D), componentwise operationsm views, and broadcasting (but without copying data)
• Mark Hoemmen : this might be a case where the tool shapes the thinking. People are used to broadcasting being an object thing, but it's really a math thing. If you merge it with array syntax, you get hard-to-debug code
• Michael Wong : operator[] with more than one index, matrix multiplication, BLAS, etc.
• (discussion ensues between the upsides and downsides of [] and (), and the advantages of mdspan)
• Michael Wong : Python uses @ as an operator to distinguish from Hadamard product
• Mark Hoemmen : will standard library implementers implement SVD? (crosses fingers)
• Patrice Roy : you can go ask them, they're not far 
• Michael Wong : that's it

Questions / answers:

• Patrice Roy : so really, the goal is to offer something like NumPy with a similar interface?
• Michael Wong : yes
• Patrice Roy : that's certainly feasible
• Vincent Riverdy : do people use boolean matrices?
• Mark Hoemmen : dense ones?
• Vincent Riverdy : yes. One bit per bool
• Michael Garland : people can do nice things with two bits
• Michael Wong : even with one bit
• Ronan Keryell : count_bits can be hardware-accelerated
• Michael Wong : I'm proposing we do some kind of NumPy interface
• Lita Lo : I think there's a desire for this. One thing I like a lot is a package named DPLYR with frames and range-like interfaces. It's really nice
• Michael Wong : it uses R, I think
• Lita Lo : yes
• Christian Trott : with the componentwise multiplication, operator overloading becomes tricky. Would a function-like interface suffice?
• Graham Lopez : it's not a new requirement / problem
• Lita Lo : you were talking about the @ operator... are we going there?
• Patrice Roy : it's been tried before. The issue is a syntax, a way to express precedence, and a way to express associativity. If we have a proposal for that, it could be useful to the community as a whole
• Andrew Lumsdaine : there are other ways than adding a new operator-definition syntax
• Graham Lopez : there are three FAQ entries on https://isocpp.org/ for matrix access. All use parenthesis
• Christian Trott : the , in [] proposal, would it be done for 23? I'm not convinced
• Christian Trott : using [] for multidimensional indexing is hard to do without losing performance
• Ronan Keryell : if that's true, there's probably something missing in the subspan
• (discussion on array traversal ensues)
• Patrice Roy : I recommend you try it and bring numbers
• Bob Steagall : I thought today's SG14 and SG19 meetings were successful. Are you planning on doing this again in the future?
• Michael Wong : yes. We can probably do even better next time
• Michael Wong : next call will be March 8^th.

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 Adelstein-Lelbach maintenant. Bryce Adelstein-Lelbach : 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 Adelstein-Lelbach : 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 Adelstein-Lelbach : 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.

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 Adelstein-Lelbach : 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.

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.