À propos de WG21, Kona 2015

Disclaimer

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

Début du contenu technique

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

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

Fin du contenu technique

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

Core Issue 2001: non-directive is underspecified

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

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

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

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

Ok.

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

Remove Deprecated Use of the register Keyword

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

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

Remove Deprecated operator++(bool)

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

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

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

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

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

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

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

Core Issue 1895: Deleted conversions in conditional operator operands

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

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

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

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

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

Rewording inheriting constructors (core issue 1941 et al)

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

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

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

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

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

Core Issue 1776: Replacement of class objects containing reference members

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

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

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

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

On parle du risque de :

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Supposons que T soit un type respectant les règles du Standard Layout
• Supposons que x soit le premier attribut d'un T
• Supposons obj de type T
• Alors &obj et &obj.x sont la même adresse, mais on ne peut accéder légalement à obj par &obj.x et on ne peut accéder directement à obj.x par &obj (ergo : faut y aller proprement, par avec des mensonges).

Par contre, ceci est correct :

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

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

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

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

On revient sur Core Issue 1895

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

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

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

... nous voulons permettre cela :

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

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

• Quel sens donner à un variant par défaut? Est-ce même permis?
• Y a-t-il une type « variant vide », et si oui, permet-on de tester cet état puisque cela encourage de mauvaises pratiques de programmation?
• Un variant peut-il contenir plusieurs éléments du même type?
• Que faire lors du remplacement d'une valeur dans un variant par une autre?
• Quelles sont les garanties à offrir si un des éléments d'un variant lève une exception lors d'un mouvement?

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

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

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

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

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

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

• Il n'y a pas d'état « vide » naturel pour plusieurs types que l'on voudrait placer dans un variant
• Si on force un type vide dans tout variant, le code client devra tester pour sa présence et on se retrouvera avec un équivalent du pointeur nul
• Il n'est pas d'avis que le type vide mène à du code plus efficace
• Selon lui, si on type fait de l'allocation dynamique de mémoire, le mouvement y sera typiquement noexcept et sa taille ne sera pas un goulot d'étranglement pour le variant
• Il préconise la garantie de base pour les exceptions, double-buffered seulement dans les cas où c'est nécessaire (le mouvement n'est pas noexcept), un état vide seulement sur une base volontaire
• Il pense que la mémoire transactionnelle pourrait permettre d'atteindre plus souvent encore une version single-buffered

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

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

Ses propositions pour P0093 et P0094 respectivement.

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

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

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

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

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

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

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

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

• Ne pas le permettre
• Le permettre vers un état vide
• Le permettre vers le premier type dans l'ordre, donc vers T0 si on a variant<T0,T1,...,TN>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Rewording inheriting constructors (core issue 1941 et al)

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

Core Issue 1776: Replacement of class objects containing reference members

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Core Issue 2047: Coordinating "throws anything" specifications

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

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

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

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

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

Ok.

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

Core Issue 2084: NSDMIs and deleted union default constructors

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Core Issue 242: Interpretation of old-style casts

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2337. shared_ptr operator*() should not be noexcept

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

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

760. The emplace issue

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

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

2510. Tag types should not be DefaultConstructible

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

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

2456. Incorrect exception specifications for 'swap' throughout library

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

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

2542. Missing const requirements for associative containers

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

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

2426. Issue about compare_exchange

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

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

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

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

Jonathan Wakely va l'écrire.

2540. unordered_multimap::insert hint iterator

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

On le marque Ready.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Core Issue 2084: NSDMIs and deleted union default constructors

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

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

Ok. On y va avec celle-là.

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

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

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

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

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

Construction Rules for enum class Values

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

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

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

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

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

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

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

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

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

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

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

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

Aaron Ballman va la retravailler et nous revenir.

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

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

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

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

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

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

D0001R1: Remove Deprecated Use of the register Keyword

Alisdair Meredith explique les principaiux changements :

• Une explication des raisons du retrait
• Des choix terminologiques plus heureux pour expliquer que l'on conserve l'ex-mot clé dans la liste des mots réservés

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

D0002R1: Remove Deprecated operator++(bool)

Alisdair Meredith explique les principaiux changements :

• On n'est déjà pas vraiment compatibles avec C, qui supporte operator--(bool), alors la section qui décrit les bris de compatibilité en est simplifiée

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

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

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

1986. odr-use and delayed initialization

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

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

À suivre.

2121. More flexible lambda syntax

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

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

1955. #elif with invalid controlling expression

Question de compatibilité avec C.

2035. Multi-section example is confusing

Changement d'ordre éditorial, pas encore fait.

2114. Missing description of incompatibility from aggregate NSDMIs

Changement d'ordre éditorial, pas encore fait.

1518. Explicit default constructors and copy-list-initialization

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

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

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

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

1743. init-captures in nested lambdas

On prend ça tel que. Ok. NAD.

2008. Default template-arguments underspecified

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

2116. Direct or copy initialization for omitted aggregate initializers

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

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

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

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

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

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

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

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

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

1710. Missing template keyword in class-or-decltype

Selon la grammaire existante, l'écriture suivante :

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1496. Triviality with deleted and missing default constructors

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

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

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

1946. exception-specifications vs pointer dereference

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

2010. exception-specifications and conversion operators

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

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

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

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

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

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

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

Plusieurs aspects intéressants de la rencontre :

• Nous sommes restés au niveau de la standardisation, et sur des aspects techniques et scientifiques, plutôt que de chercher des blâmes. C'est très plaisant de pouvoir discuter sainement de questions aussi épineuses que celles au coeur des échanges dans ces circonstances
• À WG21, il y a une forte représentation d'autres milieux que le jeu mais ayant des besoins en commun avec ce milieu : systèmes embarqués, systèmes de transactions financières, appareils temps réel du milieu de la santé, aérospatiale, voitures intelligentes, etc. de même que des représentant(e)s de groupes d'intérêt techniques (concurrence, parallélisme, calculs vectoriels, Big Data, etc.). Cela a fait en sorte à la fois d'élargir le débat et de montrer à ces divers groupes d'intérêt à quel point ils ont des besoins communs et des préoccupations connexes
• Cette reconnaissance d'intérêts communs va dans les deux sens : les gens de la finance, par exemple (je les prends à titre d'exemple, mais le même raisonnement s'applique aux autres groupes) a pu constater que ce que fait SG14 s'applique à eux, et qu'ils gagnent à participer, donc que ce n'est pas qu'une histoire pour le monde du jeu. À l'inverse, pour les gens du monde du jeu qui ont parfois l'impression d'être incompris, il y avait (je pense) lieu de constater qu'ils ne sont pas seuls

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

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

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

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

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

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

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

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

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

• Il existait une asymétrie entre la construction paramétrique et l'affectation dans la proposition. LWG n'en était pas content du tout. La question sur la table était donc de savoir si l'on permettait les conversions implicites dans les deux cas ou si l'on demandait un type exact dans les deux cas. Nous avons pris des votes après plusieurs débats, et c'était presque moitié-moitié. L'horreur! Nous avons fini par convenir qu'être moins stricts remportait un peu plus d'assentiment qu'être plus stricts (moins de contre et de très contre), alors nous irons en ce sens
• La fonction std::visit() est variadique et prend en paramètre un nombre de variants supérieur ou égal à 1, mais LWG préférerait un nombre de paramètres supérieur ou égal à zéro pour fins de généralisation en situation de métaprogrammation. Je suis d'accord, et la majorité aussi
• On a dû se demander quoi faire avec le nom de la méthode valid(), qui permet de tester le variant pour savoir s'il est valide. Dans la proposition d'Axel Naumann, si l'affectation d'une valeur à un variant échoue à l'interne, alors !valid() s'avère, mais le design actuel est pensé de manière à rendre ce cas si rare que tester la validité d'un variant devrait être extrêmement rare (et on ne veut pas encourager ce comportement pessimiste). On nous a donc demandé de trouver un nom moins invitant pour cette fonctionnalité.
  • Je suggère corrupted_by_aliens()
  • Un autre suggère the_world_is_burning()
  • David Sankel est plus raisonnable et suggère in_exception_caused_error_state()
  • Un autre suggère in_failed_assignment_error_state()
  • Il y en a d'autres : broken(), broken_variant(), exceptional(), unvariant(), partially_formed(), ill_formed(), ready() (mais semble que LWG soit très hostile à ceci pour les mêmes raisons que pour valid()), good(), corrupted(), busted(), correct(), zombie() (on nous dit que Stephan T. Lavavej aimait bien ceci)), is_zombie(), etc.
• On a fini par corrupted_by_exception() après deux rondes éliminatoires de vote

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Remaining design issues for Coroutines

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Les alternatives sont proposées :

• Ne rien faire (statu quo, la vie continue, mais ça a des conséquences irritantes qui sont les facteurs motivant sa proposition)
• Garantir le Copy Elision autrement, mais Richard Smith n'est pas sûr comment on pourrait y arriver

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

P0128R0 constexpr_if (Ville Voutilainen)

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

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

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

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

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

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

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

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

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

• Walter E. Brown est parvenu à nous rejoindre à temps, une bonne nouvelle étant donné que la proposition de Karl-Étienne Perron s'inscrivait à la suite d'une de des propres propositions
• J'ai présenté les idées de la proposition de mon mieux
• Là où j'avais l'impression qu'EWG se dresserait, j'ai contacté l'auteur au cours des jours précédants pour voir s'il y avait des pistes pour assouplir ses positions sans les dénaturer. Karl-Étienne Perron a donné son avis, et j'ai respecté du mieux que je l'ai pu sa vision comme je la comprenais
• Il y a eu plusieurs questions et plusieurs commentaires, la majorité cosntructifs
• Les travaux à faire me semblent s'inscrire dans la foulée d'autres travaux de modernisation contemporains du langage (concepts, intervalles, Pattern Matching), ce qui est intéressant, et les propositions d'EWG m'ont semblé raisonnables.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Mike Spertus propose de permettre des trucs comme :

auto p = pair(2,3.5);

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

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

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

Évidemment, il indique qu'avec ceci :

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

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

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

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

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

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

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

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

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

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

On accueille les rapports des groupes d'étude :

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

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

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

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

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

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

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

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

On aborde ensuite les groupes de travail.

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

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

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

On aborde les motions de CWG :

• P0164 (Core Issue 1734) : unanime
• P0001R1 (remove register) : consensus pour
• P0012R1 (remove operator++(bool)) : consensus pour
• P0061R1 (making exception specifications part of the type system) : consensus pour, mais il y a beaucoup d'abstentions
• P0061R1 (__has_include) : consensus pour
• P0134R0 (donner un nom qui a de l'allure à NSDMI) : unanime. Bjarne Stroustrup dit espérer ne pas voter chaque petit changement terminologique. Mike Miller dit que celui-ci changeait beaucoup de texte dans le standard
• P0136R1 (constructeurs hérités) : unanime
• P0160R0 (modifier les défauts pour les Unary Folds). Ville Voutilainen se lève pour dire que ce changement rendra les Unary Folds très difficiles à utiliser. Bjarne Stroustrup dit qu'il préférerait un remplacement avant une suppression. John Spicer fait remarquer que cette proposition émerge d'EWG. Ville Voutilainen dit qu'il parlait en son propre nom, et au nom de son pays, pas au nom d'EWG. Vote : consensus pour, mais avec beaucoup plus d'abstentions que de prises de position. On reviendra sur celle-là lors d'une rencontre ultérieure

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

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

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

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

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

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

Motion 6, P0007R1, constant_view. Unanime

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

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

Motion 9, P0074R0, rendre owner_less plus flexible. Unanime

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

On poursuit les votes.

Motion 11, P0050 (observer_ptr et autres) unanime

Motion 12, Library Fundamentals TS2, unanime

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

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

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

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

Jeffrey Yasskin prend la scène

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

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

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

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

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

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

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

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

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

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

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

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

Le vote est pris. Consensus pour

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

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

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

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

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

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

2149. Brace elision and array length deduction

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

2150. Initializer list array lifetime

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

2151. Exception object is not created

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

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

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

2153. pure-specifier in friend declaration

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

2154. Ambiguity of pure-specifier

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

2155. Defining classes and enumerations via using-declarations

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

2156. Definition of enumeration declared by using-declaration

Connexe

2157. Further disambiguation of enumeration elaborated-type-specifier

Truc grammatical

2158. Polymorphic behavior during destruction

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

2159. Lambda capture and local thread_local variables

L'exemple est intéressant :

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

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

2160. Issues with partial ordering

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

2161. Explicit instantiation declaration and "preceding initialization"

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

2162. Capturing this by reference

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

2163. Labels in constexpr functions

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

2164. Name hiding and using-directives

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

2165. Namespaces, declarative regions, and translation units

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

2166. Unclear meaning of "undefined constexpr function"

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

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

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

2168. Narrowing conversions and +/- infinity

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

2169. Narrowing conversions and overload resolution

Exemple amusant :

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

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

2170. Unclear definition of odr-use for arrays

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

2171. Triviality of copy constructor with less-qualified parameter

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

2172. Multiple exceptions with one exception object

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

2173. Partial specialization with non-deduced contexts

Truc amusant. Ceci :

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

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

2174. Unclear rules for friend definitions in templates

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

2175. Ambiguity with attribute in conversion operator declaration

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

operator int [[noreturn]] ();

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

2176. Destroying the returned object when a destructor throws

Richard Smith propose l'exemple suivant :

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

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

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

2177. Placement operator delete and parameter copies

RS dit que celle-ci laisse des cicatrices :

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

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

2178. Substitution of dependent template arguments in default template arguments

Ceci confond nos compilateurs :

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

Jens Maurer propose P1.

2179. Required diagnostic for partial specialization after first use

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

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

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

2180. Assignment operators and potentially-constructed subobjects

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

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

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

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

Gabriel Dos Reis explique :

• Un module est une collection d'unités de traduction
• L'interface d'un module contient les noms exportés
• À l'intérieur d'un module, les règles du standard s'appliquent
• Ce qui n'est pas exporté n'est visible qu'à l'intérieur du module
• Un module a un nom
• Il existe un « module global », qui couvre tout ce qui existe actuellement, ce qui fait en sorte que le code actuel compile tel quel

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Le dessin de Gor Nishanov ressemble à ceci :

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

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

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

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

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

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

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

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

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

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

1496. Triviality with deleted and missing default constructors

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

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

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

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

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

1255. Definition problems with constexpr functions

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

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

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

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

1271. Imprecise wording regarding dependent types

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

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

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

1341. Bit-field initializers

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

Richard Smith propose un exemple horrible :

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

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

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

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

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

On convient de NAD.

1638. Declaring an explicit specialization of a scoped enumeration

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

1699. Does befriending a class befriend its friends?

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

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