À propos de WG21, Issaquah 2016

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 en relief, comme celui-ci. Si vous ça ne tombe pas dans vos cordes, passez par-dessus.

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

Fin du contenu technique

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

• Mes étudiant(e)s du monde du jeu vidéo ont souvent fait remarquer que la génération de grande qualité que l'on obtient avec les outils de <random> tend à se faire au coût d'un temps d'exécution plus élevé. Walter E. Brown me fait remarquer qu'il existe un générateur, le linear_congruential_engine, qui est plus rapide mais qui a une période de cycle plus courte que les générateurs plus puissants comme mt19937 (le Mersenne Twister). C'est à essayer pour voir si ça peut suffire pour combler les besoins des gens du monde du jeu
• Aussi. on m'a fait remarquer cette année que la distribution uniforme sur des entiers est plus rapide que la distribution uniforme sur des nombres à virgule flottante. Walter E. Brown me confirme que c'est bel et bien une propriété intrinsèque du domainde de ce problème; par contre, alors que les générateurs eux-mêmes sont normés au bit près, il existe plusieurs algorithmes pour réaliser les distributions des nombres générés, et les vendeurs ont la latitude d'adopter les algorithmes de leur choix, alors il se peut que la rapidité et la qualité des distributions varient d'un compilateur à l'autre
• Enfin, il s'avère que les distributions peuvent être Stateful, ce que je ne savais pas (Walter E. Brown m'a raconté qu'il existe une stratégie de distribution qui génère deux valeurs à la fois, en retourne une et met l'autre en Cache pour répondre plus rapidement à la prochaine demande). C'est une chose à retenir, car cela signifie qu'il faille passer les distributions par référence non-const, pas par ref-vers-const ou par valeur. Je vais devoir réexaminer mon code car je ne pense pas le faire ainsi de manière générale.

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

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

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

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

ES3

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

US4

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

US28

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

US72

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

• Richard Smith suggère d'attendre pour voir ce qui arrivera à std::byte. Il aimerait voir si nous continuons d'utiliser char ou unsigned char pour gérer l'espace d'entreposage ou si on passe désormais par std::byte
• Thomas Köppe : ceci ne brisera-t-il pas le code existant?
• Richard Smith : ça n'existait pas auparavant
• Mike Miller :il faudra en rediscuter en temps et lieu

US87

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

• Mike Miller :rappelle que nous avons passé ce dossier en revue de manière très détaillée
• Richard Smith : le changement proposé me semble améliorer le texte
• Hubert Tong : à mes yeux, il n'est pas clair que ce soit une amélioration
• Roger Orr : d'accord. Il me semble que le volet Delegation of Progress n'est plus clair avec ce changement. Forward progress serait plus clair
• Thomas Köppe mais nous définissons « progression » ici
• Mike Miller :suggère de donner ceci à SG1
• John Spicer : considérant les efforts déjà investis ici, à moins que les améliorations ne soient significatives, je suggère qu'on n'y touche pas

US96

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

• Richard Smith est d'avis qu'on devrait l'accepter
• Thomas Köppe : il y a des précédents au recours à une base 1, mais la base zéro est plus près des usages
• Richard Smith : dans la terminologie existante, il y a un cas au paragraphe 4 où ce changement poserait problème; il faudrait parler de l'élément 'i+1' dans ce cas, ou quelque chose de semblable
• Mike Miller : accepté, changement éditorial

US98

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

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

• Richard Smith : je ne vois pas de Reference Binding dans cet exemple
• Thomas Köppe : il me semble que le problème est mal posé. Il n'y aurait pas de problème avec const auto&. Il y en aurait un avec make_pair() et auto&
• Mike Miller : ce n'est pas un problème

US103

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

• Mike Miller : ajoutons-nous un exemple?
• Jason Merrill : je ne pense pas qu'on doive expliquer l'alocateur ici
• Mike Miller : y a-t-il un exemple dans le texte proposé?
• Jason Merrill : non, mais ce serait une bonne chose
• Mike Miller : Jens Maurer dit qu'il a un exemple. On l'ajoute

US166

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

• Richard Smith : je ne veux pas ajouter ce genre de truc à l'annexe C
• Hubert Tong : je pense que C.1 liste les retraits...
• Richard Smith : C.1 fait la liste des extraits de code C qui ne sont pas des extraits de code C++ valides, pas le contraire
• Mike Miller : rejetons-nous ceci?
• Richard Smith : je pense que la dernière phrase indique que ce n'est pas un Core issue. LWG? Ça devait appartenir à un autre commentaire
• Mike Miller : on le rejette alors

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

• Richard Smith : ce commentaire était marqué comme éditorial et je l'ai traité ainsi
• Hubert Tong : si c'est supposé être du C11, Ok. Si c'est supposé être du C99, il nous manque quelque chose
• Richard Smith : la section clé ne semble pas avori changé entre les deux; les changements à réaliser ne semblent pas importants
• Mike Miller : ceci ne semble pas affecter Core. Ça devrait aller à LWG
• Hubert Tong : l'énoncé de 1.1p2 dit que « C++ is based on... », mais C++ n'est pas vraiment basé sur C99, et n'est clairement pas basé sur C11
• Richard Smith : devrions-nous dire « based on C90 »?
• John Spicer : « inspired by a true story »?
• Mike Miller : « tracing its heritage to... »?

GB5

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

• Roger Orr : Jens Maurer a proposé un peu de terminologie
• Mike Miller : j'aimerais attendre Jens Maurer pour en discuter

GB6

La critique est subtile :

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

• Richard Smith : en plus du changement demandé, il faut tenir compte de SFINAE
• Jason Merrill : quel changement?
• Richard Smith : on parle de deux cas « parallèles »
• Hubert Tong : il nous faut un ajustement semblable pour « ill-formed »
• John Spicer : ça me semble superflu. Pour constexpr, on ne se rend jamais au cas qui pose problème
• Jason Merrill : je pense qu'une note nous permettant d'éviter les problèmes serait utile
• Hubert Tong : dans le cas « ill-formed », nous ne l'atteignons jamais. Le cas de comportement indéfini a besoin d'un peu de terminologie
• Jason Merrill : on ne fait pas ce qui pose probème, n'est-ce pas?
• John Spicer : on abandonne avant de se rendre là
• Mike Miller : une note, simplement?
• John Spicer : la note dirait « ceci n'est pas vraiment du comportement indéfini »
• Richard Smith ...ce qui n'est pas ce que Jens Maurer a écrit. Je pense qu'on devrait accepter ses mots tels quels

GB7

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

• Mike Miller : dossier éditorial. Richard Smith nous recommande d'accepter
• Hubert Tong : ceci interagit avec std::byte
• Mike Miller : remplace-t-on unsigned char avec std::byte?
• Richard Smith : le deuxième placement new ne termine pas la vie de l'objet
• Hubert Tong : les deux tableaux sont encore dans leur propre durée de vie
• Richard Smith : la question est de savoir si les deux tableaux sont encore en vie
• Faisal Vali : j'ai eu de la difficulté avec ce passage aussi
• Mike Miller : accepté, éditorial

GB8

• Mike Miller : dossier éditorial. Richard Smith nous recommande d'accepter
• Jason Merrill : la nouvelle terminologie me sied
• Mike Miller : accepté, éditorial

GB9

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

• Hubert Tong : je suis en désaccord avec le commentaire tel que présenté, car la taille des objets importe. Le texte proposé est incorrect
• Richard Smith : je ne suis pas certain que nous définissions vraiment la taille des sous-objets
• Hubert Tong : c'est une propriété observable pour laquelle il est possible d'écrire un test
• Thomas Köppe : je peux faire un tableau est passer itérativement de l'un à l'autre
• Mike Miller : nous ne disons pas clairement ce qu'est un sous-objet
• Thomas Köppe : je peux prendre l'adresse d'un objet et la comparer avec l'adresse d'un sous-objet
• Richard Smith : il n'y a pas de définition claire de ce concept qui tiendrait compte des classes de base virtuelles
• Richard Smith : il n'y a pas nécessairement une séquence continue de bytes à examiner
• Richard Smith : le problème à adresser est celui de la définition formelle d'EBCO
• Hubert Tong :la résoluton proposée par Jens Maurer ne change pas vraiment la situation
• Richard Smith : pour l'instant, la notion de size of a base subobject n'a pas vraiment de sens
• Richard Smith : si nous conservons ce passage, il faut lui donner un sens
• Hubert Tong suggère un test pour vérifier si un base class subobject est de taille zéro
• Thomas Köppe : nous pourrions dire que every base subobject occupies its unique storage, ce qui permettrait de tenir compte des objets occupant zéro bytes comme occupant un espace qui leur est propre
• Thomas Köppe : dans ce cas, la taille de l'objet différerait de la taille de son type
• Mike Miller : que faisons-nous?
• Richard Smith : il nous faut définir size of a base class subobject
• Hubert Tong : ce sera « accepté avec modification » si nous faisons ce changement

GB13

• Mike Miller : dossier éditorial. Richard Smith nous recommande d'accepter
• Mike Miller : accepté, éditorial

GB14

• Hubert Tong : semble éditorial
• Mike Miller : accepté, éditorial

GB15

Ce cas vise du code comme :

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

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

• Hubert Tong : la référence... disparaît
• Richard Smith : si nous capturons par référence ici, nous n'avons pas de règle qui dise que nous créons un attribut dans ce cas. Ceci fonctionnait par le passé car nous n'avions pas de règle pour la durée de viue des références. Ça ne fonctionne plus avec le texte existant
• Mike Miller : c'est en Review Status

GB19

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

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

• Patrice Roy : ouais, celle-là est étrange
• Richard Smith : oups!
• Mike Miller : on accepte?
• Richard Smith dit que Jens Maurer a une terminologie à proposer

GB23

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

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

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

• Hubert Tong dit que Jens Maurer a deux options terminologiques à proposer
• Mike Miller : on peut attendre son arrivée
• Thomas Köppe : qui ferait ça? Est-ce un réel problème?
• Hubert Tong : une note ne ferait pas de tort
• Thomas Köppe : une note serait une chose polie
• John Spicer : ceci n'est pas un nouveau problème, n'est-ce pas?
• Hubert Tong : c'est là depuis toujours
• John Spicer : ça tombe dans la catégorie de do that and bad things will happen
• Richard Smith : une note, rien de plus
• Mike Miller : accepté alors

GB24

• Mike Miller : dossier éditorial. Richard Smith nous recommande d'accepter
• Mike Miller : devrions-nous utiliser final? Ce n'est pas le terme explicatif usuel
• Richard Smith : c'est un exemple
• Mike Miller : accepté, éditorial

GB25

• Hubert Tong : ceci recoupe l'initialisation des fonctions gérant des exceptions
• Richard Smith : acceptons avec quelque chose qui ressemble à la terminologie proposée par Jens Maurer

GB26

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

• Mike Miller SG1?
• Patrice Roy : c'est un enfant du mal. Il faut s'en débarrasser
• Richard Smith : on n'a pas à le renvoyer à SG1 à mon avis. C'est un vrai problème
• Mike Miller : il n'y a pas de résolution proposée
• Richard Smith dit que Jens Maurer propose deux résolutions possibles
• Mike Miller : attendons-le

GB63, GB64 et GB65

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

• Hubert Tong : tant que la limite n'est pas ridicule...
• Richard Smith : ces chiffres sont un guide, sans plus
• Thomas Köppe : nous n'imposons pas de telles limites minimales pour le moment
• Richard Smith : on pourrait simplement retirer l'annexe B
• Richard Smith : d'un autre côté, c'est utile d'offrir une forme de référent de base pour les implémentations
• John Spicer : 64?
• Richard Smith : c'est trop peu en pratique
• John Spicer : en pratique, les gens utilisent des zillions (sic.)
• Richard Smith : 16K?
• Hubert Tong : j'ai vu des implémentations ramper sous la pression
• Mike Miller : on statue : 16K pour GB64, 256 pour GB63, 256 pour GB65. Accepté

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

• Mike Miller : Hans Boehm m'a dit que SG1 serait heureux de se défait du mot forward devant progress. Sommes-nous à l'aise avec cela&
• Roger Orr : dans le paragraphe entier ou seulement dans la section qu'on nous a indiquée?
• Mike Miller : attendons de voir le texte proposé

RU1

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

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

• Patrice Roy : c'est amusant, ça
• Hubert Tong : c'est passé sur le Reflector de CWG
• Hubert Tong : je n'ai jamais vu ça comme étant sur le territoire de CWG. Ça me semble être une décision de design
• Mike Miller : Ok, on l'envoie à EWG

JP2

• Mike Miller : dossier éditorial. Richard Smith nous recommande d'accepter
• Hubert Tong : considérant que le changement a déjà été appliqué au document...
• Mike Miller : accepté

JP3

• Mike Miller : dossier éditorial. Richard Smith nous recommande d'accepter
• Hubert Tong : je ne suis pas content de celui-là
• Mike Miller : moi non plus
• Jason Merrill : techniquement, operator new ne crée pas d'objets
• Mike Miller : au mieux, il participe au processus
• Mike Miller : accepté avec modifications

JP4 et JP5

• Mike Miller : erreurs typographiques. Éditorial

JP6, JP7, JP14, JP16 and JP17

• Mike Miller : Richard Smith suggère que nous les rejetions. La terminologie proposée n'a pas de sens dans le contexte

JP8

• Mike Miller : Richard Smith suggère que nous les rejetions. La terminologie existrant est correcte, et celle proposée ne porterait pas un sens approprié
• Hubert Tong : je me souviens que nous ayions discuté de cette terminologie. Aucun des changements proposés ne semble convenir
• Mike Miller : rejeté

JP10 et JP11

• Mike Miller : Richard Smith suggère que nous les rejetions. Le langage ne prend pas position sur des questions de style
• Roger Orr : j'adhère fortement à la position de Richard Smith
• Mike Miller : rejeté

JP12

• Mike Miller :c'est un problème de formatage. Richard Smith dit que c'est ce que La^Te_X fait. Il essaiera de corriger le tout mais ne fait pas de promesses
• Mike Miller : attendons de voir s'il y arrive avant de prendre position

JP15

• Mike Miller : Richard Smith suggère que nous le rejetions. Selon lui, la référence croisée existante est préférable à celle proposée
• Mike Miller : rejecté

JP18

• Mike Miller :c'est un problème de formatage. Richard Smith dit que c'est ce que La^Te_X fait. Il essaiera de corriger le tout mais ne fait pas de promesses
• Mike Miller : attendons de voir s'il y arrive avant de prendre position

CA12

Que faire avec ceci?

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

• Hubert Tong : les discussions en-ligne laissent entendre que la situation qui prévaut actuellement sied à la majorité. Il serait préférable d'éviter de faire des acrobaties avec les zones d'entreposage
• Mike Miller : ceci demeure donc du comportement indéfini. Ajoute-t-on une note?
• Hubert Tong : oui. Éventuellement, quelqu'un va découvrir ceci et se demander si nous y avions pensé. Avoir un exemple est le moyen idéal pour faire en sorte que les gens nous reviennent et nous demandent de le faire fonctionner, mais mieux vaut attendre qu'on nous le demandre
• Roger Orr : souhaitons-nous appuyer l'exemple par des explications?
• Hubert Tong : oui

Mike Miller : EWG nous a relayé quelques dossiers

US101

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

• Mike Miller : EWG souhaite que nous examinions cette question
• Hubert Tong : le terme POD est un truc dont LWG souhaite aussi se débarrasser
• Hubert Tong : il sert encore dans la définition que fait Library de char-like type (21.1). On ne peut pas l'éliminer sans que LWG ne s'en mêle
• Mike Miller : LWG va y jeter un coup d'oeil aussi
• Hubert Tong : pour les λ, il faudra un changement terminologique bien sûr, mais nous utilisons POD
• Hubert Tong : on souhaitabt probablement dire trivial, mais c'est un peu différent sur le plan sémantique. Ça semble être le seul aspect de Core Wording visé
• Maxim Kartashev : l'ABI du processeur Itanium utilise POD mais se base sur... C++ 98
• Mike Miller : enlevons-nous ce terme?
• Hubert Tong : oui. Il faut corriger la section sur les λ par contre. Il serait préférable que LWG fasse la même chose

GB20

• Mike Miller : EWG souhaite que nous examinions cette question. §8.5p3
• Mike Miller : EWG se dit d'accord avec le commentaire, mais veut un Core Review de la terminologie proposée
• Roger Orr : Jens Maurer a proposé une terminologie alternative pour ceci. On peut attendre qu'il arrive
• Mike Miller :Ok.

GB68

• Mike Miller : EWG souhaite que nous examinions cette question : Forward to Library and Core
• (beaucoup de rires dans la salle devant le passage indiquant « the term literal type is dangerous »)
• John Spicer : on en a déjà discuté
• Hubert Tong : on a quelques cas, comme pour constexpr. Un literal type est un peu le cas opposé. 'Could be', mais pourrait ne pas fonctionner. Pouvons-nous parler d'un possibly literal type?
• John Spicer : je le garderais tel quel. Ça ne fait pas de mal
• Hubert Tong : ça fait longtemps qu'on connaît ce problème
• John Spicer : on pourrait insérer une note dans §3.9 pour indiquer le sens de literal type
• Hubert Tong : que l'on accepte ou que l'on rejettre la proposition, ça revient au même dans ce cas-ci
• John Spicer : §3.9 explique comment déterminer si un type est un literal type, mais ne dit pas quel sens donner à cet énoncés
• Mike Miller : ajoutons-nous une note pour clarifier le sens?
• John Spicer : oui, c'est ce que je souhaite
• Mike Miller : il nous faudrait une proposition terminologique.
• (John Spicer s'en occupe)

P0057R6 Wording for Coroutines (Gor Nishanov)

• Mike Miller : nous avons tenu une téléconférence il y a quelques mois. Où en sommes-nous?
• Gor Nishanov : j'ai fait les changements demandés et inséré (avec beaucoup de difficultés!) les balises requises pour mettre les changements en relief.
• Gor Nishanov : certains changements ont été faits pour réduire l'exposition des exceptions, dans §8.4.4. Toutefois, ceci pourrait laisser certaines coroutines dans un état impossible à détruire, alors certains changements sont devenus obligatoires
• Gor Nishanov : pour ce qui est de get_returned_object(), page 12, le code était incorrect pour les coroutine de type void, alors nous avons enlevé l'exemple de code pour le remplacer par de la terminologie
• Mike Miller : §8.4.4.p5, problème de formatage
• Dinka Ranns : §3.7.4.1p4, la première phrase est étrange (trop de « or »)
• Jason Merrill : §5.3.8 est difficile à lire
• Gor Nishanov explique l'intention. Ajouter un « or »? Et ajouter suspend point
• Jason Merrill : §5.3.8 les puces 3.2 et 3.3 peuvent être fusionnnées
• Dinka Ranns : §5.3.8 puce 3.2, il n'est pas clair que l'on parle d'un cast-expression
• Hubert Tong : à titre de commentaire méta-éditorial, ce document se présente comme une série de changement en comparaison avec la version précédente...
• Gor Nishanov : c'était une demande de John Spicer
• Dinka Ranns : il serait plus facile de comprendre le sens de ce phrases si les objets discutés étaient nommés plus tôt dans les phrases
• Jason Merrill : §3.5 devra peut-être être ajustée pour traiter de Copy Elision
• Mike Miller : c'est parce que le document se base sur la version précédente du standard
• Hubert Tong demande si on peut ajouter une note à §5.1 indiquant quoi faire quand un type autre que bool est retourné. Les deux seuls cas possibles semblent être void ou bool
• Hubert Tong : je n'aime pas la formulation des contraintes sur l'énoncé return. Pouvons-nous clarifier ce qui est retourné dans §6.3.3?
• Gor Nishanov : dans une coroutine, il faut utiliser co_return. Dans une non-coroutine, il faut utiliser return
• Hubert Tong : pourquoi par « return shall not be used in a coroutine »?
• Roger Orr : et dans l'autre sens?
• Hubert Tong : « shall only appear »?
• Patrice Roy : et si on trouve une λ contenant un return dans une coroutine?
• Gor Nishanov : il y a une section sur l'interaction entre λ et coroutines, où nous discutons de co_await, dans §5.3.8 p2
• Dinka Ranns : peut-on « tomber hors » d'une coroutine? Je ne vois pas de terminologie en ce sens
• Roger Orr : je pense que c'est couvert par le paragraphe 4
• Gor Nishanov : devrais-je répéter §6.3.3 mais à propos des coroutines?
• Richard Smith : nous avons un énoncé général dans §7p4 qui trace une distinction entre « shall not appear in... » dans le cas de  λ , mais je ne suis pas sûr qu'il s'applique ici
• Hubert Tong : pouvons nous simplement traiter le cas du return? (on essaie diverses formules, c'est subtil)
• Mike Miller : « a coroutine shall not return to its caller by the return statement »?
• Gor Nishanov : Ok
• Hubert Tong : ça fonctionne
• Mike Miller : §8.4.4p11, le text sur la durée de vie des copies des paramètres est suspect (Mike Miller suggère une formule)
• Jens Maurer : quand je suis une coroutine, puis-je référer à des trucs qui seraient correctes dans une fonction « régulière » mais donneraient dans le comportement indéfini avec une coroutine? Par exemple, passer une référence...
• Gor Nishanov : oui, de la même manière qu'on pourrait frapper du comportement indéfini si la durée de vie d'une λ devait excéder celle d'une référence qu'elle aurait capturée
• Jens Maurer : où est-ce écrit?
• Gor Nishanov : ça me semble implicite
• Jens Maurer : dans le cas d'une λ, nous avons de la terminologie très élaborée pour expliciter les attentes. Puisque nous parlons ici de coroutines Stackless, je pense qu'il nous faut de la terminologie ici aussi
• Gor Nishanov : j'aimerais rester à un plus haut niveau ici qu'avec les λ
• Roger Orr : la terminologie des λ peut servir d'inspiration tout de même
• Jens Maurer : où indique-t-on que la suspension d'une coroutine, suivie d'un resume, la replace précisément dans l'état où elle était auparavant?
• Gor Nishanov : §1.9 le dit à propos d'objets de durée automatique (sur la pile, techniquement), mais ne parle pas d'objets passés par référence
• Faisal Vali : si nous résumons la coroutine avant que l'appelant ne se termine, tout va bien
• Hubert Tong : la terminologie dont nous dépendons insiste sur « objects of automatic duration »
• Jens Maurer : ... donc les références ne sont pas couvertes, car on mentionne explicitement « objects »
• Jens Maurer : il nous faut un correctif ici, bien que la défectuosité soit préexistante. Aussi, en recevant un signal, nous exécutons le gestionnaire du signal, après quoi nous retournons au site original où tout est tel qu'il l'aurait été si le signal n'avait jamais été émis (dans la mesure où le traitement du signal ne l'a pas détruit)
• Gor Nishanov : quand une coroutine est suspendue, elle retourne vers l'appelant. §5.3.8, await-expression, puce 5.1. « Control-flow returns to the caller » décrit le comportement à adopter lors d'une suspension
• Jens Maurer : on devra retravailler le texte, du fait que le texte préexistant indique que tous les objets locaux sont détruits lorsque le flux d'exécution retourne vers l'appelant
• Patrice Roy : il faudra réécrire d'autres clauses du standard pour tenir compte de cette nouvelle réalité
• Jens Maurer : à tout le moins, avec références croisées vers les sections appropriées, et une note non-normative pour expliquer la nuance
• Richard Smith : il faut en quelque sorte « garder un doigt sur la fonction qu'on a quitté, mais pas vraiment quitté »

On reprend vers 15 h 35.

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

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

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

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

US28 : incorrect definition for principal constructor

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

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

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

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

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

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

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

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

US103 :

Mike Miller : faudrait un exemple.

Jens Maurer : en voilà un :

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

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

Jens Maurer : Ok, je vais faire ça.

GB5 : definition of template parameter

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

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

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

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

Richard Smith propose une formulaton qui semble pas si mal.

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

GB6 : definition of undefined behavior vs. constexpr

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

Jason Merrill : on veut simplement une note

Le texte proposé est :

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

GB9 : base class object of zero size

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

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

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

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

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

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

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

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

GB19 : missing cv-qualification when materializing a temporary object

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

GB20 : decomposition declaration should commit to tuple interpretation early

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

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

Ce sera proposé pour vote vendredi.

GB23 : disallow handlers taking a reference to array or function

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

Ce sera proposé pour vote vendredi.

GB25 : imprecise description when terminate is called

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

GB26 : 'last' active handler and multithreading

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

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

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

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

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

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

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

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

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

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

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

GB63, GB64 et GB65

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

GB67

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

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

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

Introduce the term "direct member"

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

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

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

RU1

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

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

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

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

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

US28

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

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

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

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

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

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

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

US103

Jens Maurer a ajouté un exemple d'utilisation :

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

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

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

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

Jens Maurer retouche et propose :

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

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

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

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

GB5

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

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

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

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

GB6

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

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

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

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

US6

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

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

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

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

P0195R1 : Modernizing using-declarations

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

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

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

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

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

D0195R2: Pack expansions in using-declarations

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

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

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

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

P0329R1: Designated Initialization Wording

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

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

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

Quelques exemples :

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

Patrice Roy demande si C supporte un truc comme :

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

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

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

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

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

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

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

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

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

On fait quelques simplifications au texte par la suite.

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

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

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

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

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

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

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

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

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

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

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

Mike Miller : on abordera maintenant les modules.

Gabriel Dos Reis : deux documents sont à examiner.

C++ Module TS Issues List

On a plusieurs trucs à examiner.

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

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

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

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

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

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

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

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

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

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

Import declaration and namespace partitions

La question suivante a été posée :

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Gabriel Dos Reis nous quitte et reviendra demain.

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

D0003R5: Removing Deprecated Exception Specifications from C++ 17

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

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

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

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

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

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

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

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

US 28: incorrect definition for principal constructor

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

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

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

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

On le votera vendredi.

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

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

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

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

On le votera vendredi.

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

D0057R7: Wording for Coroutines

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

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

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

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

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

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

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

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

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

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

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

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

Non-DR : US103, GB19, GB20, GB65

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

P0306R1: Comma omission and comma deletion

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

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

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

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

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

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

• Il y a du contenu dans __VA_OPT__ et il doit être isolé du reste du code. On pourrait réaliser la substitution interne d'abord, en entier. Ensuite, le __VA_ARG__ pourrait s'appliquer, en utilisant le Placemarker Token
• L'autre est de traiter la bête comme une sorte de fonction : si la séquence est vide, elle s'étend à rien, sinon elle se remplace par ses paramètres, mais cela rend illégal le recours à de la construction de jetons par ##

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

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

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

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

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

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

Jens Maurer pense avoir une terminologie pour ceci.

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

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

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

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

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

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

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

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

Les points de discussion ce soir sont :

• Les nombres pseudoaléatoires
• Les nouvelles fonctions numériques
• Les types primitifs
  • short float
• Traits et alias
  • contrôler le nombre de bits impliqués
• Utilitaires
  • manipulation de bits, constexpr ou non
  • itérer sur des bits
  • unités de mesure
• Arrondissement, débordement
  • arithmétique détectant les débordements
  • arithmétique de double taille
  • arithmétique multi-mots mémoire
  • arithmétique « sécuritaire »
  • contrôler l'arondi et le débordement
• Nombres à virgule flottante décimaux
• Littéraux hexadécimaux flotttants – Thomas Köppe fait remarquer que c'est déjà accepté pour C++ 17
• Entiers non-signés non-modulaires
• Entiers illimités
• Rationnels illimités
• Nombres à virgule flottante illimités (?)
• Arithmétique à point fixe (il reste à fusionner ce que fait Lawrence Crowl et ce que fait John McFarlane)
  • on a plusieurs autres nombres limités en taille à traiter
• Conversions de formats, spécialisables pour fins de « performance »

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

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

Lawrence Crowl : d'accord.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Walter E. Brown présente la requête pour un TS de <random>
  • Walter E. Brown  dit qu'on veut un germe plus simple, on a des gens qui veulent des nombres « précis » (de meilleure qualité) et qu'on a des gens qui veulent des nombres générés « rapidement »
• Walter E. Brown présente de nouveaux traits numériques
  • Nathan Myers se demande à quel point ça demeure utile depuis constexpr
  • Walter E. Brown dit que ça fait partie du questionnement

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

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

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

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

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

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

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

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

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

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

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

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

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

US 93: argument evaluation order when calling an operator function

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

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

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

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

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

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

• Maxim Kartashev : § 7.1.7.2 pour les template template parameters, on devrait changer shall name pour shall refer to
• Richard Smith : ça ne me semble pas essentiel, mais je peux le faire de manière éditoriale
• Thomas Köppe : y a-t-il un risque?
• Hubert Tong : ça passerait mal devant une « lecture hostile »
• Richard Smith : avons-nous besoin du mot-clé template ici? (pas clair...)
• Mike Miller : que faisons-nous?
• Hubert Tong : nous planifions remplacer « template-name corresponding to a class template » jusqu'à la virgule par « if the type is a placeholder for a deduced class type »
• Richard Smith : outre cela, ça me convient
• Hubert Tong : il existe des cas où simple-type specifier n'est pas une bonne idée, p. ex. : §7.1.7.2p2
• Richard Smith : ajoutons-nous une forme de blanket wording?
• Hubert Tong : des restrictions?
• Richard Smith : nous ne disons pas comment faire correspondre un simple-type specifier au type qu'il nomme. Nous devrions expliquer le sens de ce terme
• Hubert Tong : si on utilise une forme de blanket wording, les gens vont devoir le chercher
• Richard Smith : je suis certain qu'il existe un Core Issue indiquant que 15.6p3 est terrible
• Roger Orr : ceci ne constituerait-il pas un changement distinct de celui que nous étudions présentement?
• Richard Smith : en effet.
• Richard Smith : je suis à l'aise avec la terminologie de Jens Maurer une fois que les ajustements dont nous venons de discuter auront été appliqués.

FI 20: decomposition declarations with parentheses

• Hubert Tong : quelle est la position d'EWG sur ce dossier?
• Richard Smith : si on peut le faire fonctionner cette semaine dans le temps à notre disposition, alors Ok
• Mike Miller : ils ont pris un Straw Poll et c'était partagé, donc la consigne est « corrigez-le si c'est raisonnable »
• Richard Smith : on peut y arriver
• (l'extrait de phrase « the declaration is never interpreted as a function declaration and » divertit les gens dans la salle)
• Thomas Köppe : oh, un mécanisme pour contourner le Most Vexing Parse. Charmant!
• Hubert Tong : ça laisse entendre que la réécriture est notionnelle, et ne provoquerait pas une situation de Vexing Parse au passage
• Mike Miller : la terminologie convient-elle? Semble que si

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

• On la marque Ready en tant que DR.

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

• Richard Smith : il y a un risque de provoquer l'initialisation d'une variable non-locale si son premier cas de ODR Use se trouve dans un gestionnaire de signal. Il faudrait qu'on en informe SG1
• Jason Merrill : la terminologie n'exclut pas le cas d'une portée de niveau namespace
• Richard Smith : oui, c'est vrai qu'il est possible de lire ce texte et de contourner le problème
• Hubert Tong : dans la section propose à Library, la deuxième puce pour le changement dans §18.10.5 devrait indiquer « if a... » plutôt que « if the... »
• Hubert Tong : la dernière puce est suspecte. Devrions-nous émettre un énoncé plus fort tel que « one shall not access... » pour éviter les risques d'ODR Use? ODR Use devrait être utilisé dans certains cas
• Richard Smith : pour le cas « global », deuxième puce... Remplacer « access an object with thread storage duration » par « odr-use an object with thread storage duration »?
• Dinka Ranns : le « or » de la troisième puce devrait être un « and »
• Richard Smith : la présence d'un throw dans une fonction ne me pose pas de problème si on ne l'atteint pas dans un gestionnaire de signal
• Richard Smith : je ne vois pas pourquoi un parle de C là-dedans
• Richard Smith : le texte semble exiger une modalité C++ d'édition des liens... Il manque probablement un extern "C" dans le synopsis de la fonction de signal

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

• Hubert Tong : ce serait utile d'avoir l'auteur (Hans Boehm) avec nous
• Mike Miller : il dirige une rencontre, alors je doute qu'il soit disponible
• Hubert Tong : nous leur ferons suivre nos préoccupations à l'effet que nous cherchons à savoir si le concept de signal-safe est une propriété de la fonction itself. Dans ce cas, il faudrait que ce soit intrinsèque à sa définition; dans le cas contraire, le concept semble moins utile
• Faisal Vali : cette propriété n'est pas complètement opaque dans la bibliothèque présentement
• Hubert Tong : soit on conserve « signal-safe function », soit un décide de parler de « signalisafe operations », dans quel cas on fait face à un comportement indéfini si une opération qui n'est pas « signal-safe » se produit pendant la gestion d'un signal
• Faisal Vali : troisième puce de §18.10.5, il y a un « and » suspect
• Hubert Tong et Thomas Köppe expliquent. Ça semble plus clair; la terminologie semble Ok.
• Mike Miller : nous informerons l'auteur que nous avons traité sa proposition

Modules issues list

• Gabriel Dos Reis : EWG a changé d'avis sur Issue 1, et a décidé de permettre export import M;
• Gabriel Dos Reis : pour Issue 2, nous pensons que la terminologie proposée permet d'éviter des cycles
• Richard Smith : je ne pense pas qu'on doive prendre la fermeture transitive dans ce cas
• Gabriel Dos Reis : c'est pour éviter les cycles entre les modules
• Gabriel Dos Reis : je peux enlever le terme « graph »
• Richard Smith : c'est « interface dependency » qui me préoccupe (on fouille, et c'est défini, donc il n'y a pas de problème sur ce plan; il existe deux règles distinctes dans la même section, d'où la confusion)
• Richard Smith fait remarquer qu'empêcher l'implémentation d'un module d'importer sa propre interface ne résout pas de problème, mais permet au compilateur d'informer les programmeuses et les programmeurs d'erreurs probables, du fait que ces interfaces sont « importées » par défaut
• Richard Smith : ce serait plus clair si nous changions de paragraphe après la deuxième phrase
• Richard Smith : peut-être remplacer les deux dernières phrases par « a module shall not have transitively happening dependencies upon itself »?
• Richard Smith : l'exemple devrait accompagner le premier paragraphe
• (Gabriel Dos Reis fait les correctifs)
• Richard Smith suggère qu'on ajoute aussi un exemple de fermeture transtitive. Gabriel Dos Reis le fera
• Dinka Ranns : dans Issue 3, « a non-inline, a non-exported, variable » devrait s'écrire « a non-inline non-exported variable »
• Patrice Roy : il y a un bogue dans l'exemple de fermeture transitive
• Gabriel Dos Reis : je vais le corriger
• Richard Smith : on devrait définir « have a dependency on » plutôt que « depends on »
• Gabriel Dos Reis : dans Issue 4, on nous avait demandé de retirer la terminologie portant sur le namespace partition
• Dinka Ranns : la terminologie de §7.7.2p1 est étrange
• Richard Smith : le passage « visible...visible » est répétitif et répétitif 
• Roger Orr fait des suggestions terminologiques. Gabriel Dos Reis met le document à jour
• John Spicer suggère l'ajout de terminologie pour que la visibilité des composants exportés soit plus explicite
• Richard Smith suggère que ce soit importé « in the same namespace and context »
• John Spicer : il faudrait ajouter un exemple et une explication pour en clarifier le sens
• John Spicer : si une fonction friend est déclarée et exportée mais si sa signature correspond à une signature préalablement donnée sans être exportée, alors la fonction est-elle exportée ou pas?
• Gabriel Dos Reis : je vais ouvrir un Issue à ce sujet
• John Spicer : que faire des non-locales static?
• Gabriel Dos Reis : il y a des moyens d'implémenter cela
• John Spicer : dans la mesure où on s'en occupe et où c'est documenté
• Thomas Köppe : suggère un exemple simplifié
• Richard Smith : dans le standard, on ne donne pas de noms de fichiers (Richard Smith suggère une formulation conforme aux usages)
• Jens Maurer demande si on doit encore traiter des résolutions dans ce document avant vendredi. Mike Miller dit que Gabriel Dos Reis va revenir nous voir avant vendredi.

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

P0266R1: Lifting Restrictions on requires-Expressions

• Walter E. Brown rappelle les diverses étapes franchies jusqu'ici par ce document
• Hubert Tong : je ne pense pas que le changement dans p7 soit cohérent avec la direction indiquée par Andrew Sutton dans l'Issues List sur les dépendances entre templates. Il y a des choses qui sont malformées parce qu'elles sont malformées, tout simplement
• Richard Smith : on ne peut faire de SFINAE que pendant la substitution. Si nous sommes en plein Parse, alors une erreur sera rigide
• Richard Smith : quel était le problème avec le  paragraphe 7 dans sa forme antérieure?
• Walter E. Brown : mon but est d'éliminer le paragraphe 4. Les changements au paragraphe 7 ont été faits à la demande de CWG. Selon ma perspective, le reste n'est que de la courtoisie
• Hubert Tong : les modifications au paragraphe 3 que nous avions demandé sont des prérequis pour votre proposition, qui est en fait le seul consommateur de ce paragraphe
• Richard Smith : le change semble avoir été demandé par LWG
• Walter E. Brown : ce devrait être CWG, c'est une erreur typographique
• Richard Smith : l'ennui avec le paragraphe 7 est qu'il de disait pas ce qui se produirait s'il y avait quelque chose de malformé dans la clause requires
• Faisal Vali : n'avons-nous pas de restriction exigeant qu'il n'y pas d'instantiation spéculative d'un template...
• Richard Smith : ce cas n'est justement pas dans un template
• Davis Herring : ceci se produirait-il dans un static_assert?
• Richard Smith : oui
• Davis Herring : pourquoi utiliserait-on requires hors d'un template?
• Richard Smith : ça pourrait faire partie d'une sorte d'assertion
• John Spicer : on pourrait tester pour la présence d'un membre d'un type de la bibliothèque, à titre de contrôle de version
• Richard Smith : ceci ressemble à une discussion que nous avons déjà eu à propos de constexpr dans un contexte non-dépendant
• Hubert Tong : utiliser des macros dans un contexte template-dependent pourrait être une motivation
• Richard Smith : ça ressemble aussi aux discussions sur static_assert dans un contexte non-dépendant
• Davis Herring : j'aurais souhaité qu'on évite des règles, une pour les contextes dépendants et une autre pour les contextes qui ne le sont pas
• Richard Smith : je pense qu'on sera Ok si on recule sur les modifications au paragraphe 7. Ill-formed is ill-formed beause that's what ill-formed means
• John Spicer : que se passera-t-il si on utilise requires dans un template à l'intérieur d'un contexte a non-SFINAE?
• Hubert Tong : en appliquant la substitution, on ne substitue pas dans l'expression requires tout de suite. On évalue plutôt requires comme une sorte de contrainte, puis on applique la substitution par la suite
• Richard Smith : ... et si ça échoue, on remplace simplement la clause requires au complet par false
• Hubert Tong : on peut y arriver sans modifier le paragraphe 7
• Walter E. Brown : est-ce que je recule aussi sur le commentaire dans l'exemple?
• Mike Miller : oui
• Walter E. Brown : ça me va
• Hubert Tong : je pense qu'on peut soumettre une motion de vote cette semaine
• Davis Herring : on peut dire qu'il s'agit d'une expression constante compile-time
• Hubert Tong : si ce n'est pas dans la liste des choses qui ne peuvent pas apparaître dans une constant expression, alors il s'agit d'une constant expression
• John Spicer : peut-être quelque chose en remplacement du paragraphe 4? Une note indiquant où une expression requires peut apparaître?
• Hubert Tong : et à propos du paragraphe 7 non-modifié... Que fait-on des λ?
• Richard Smith : oui?
• Hubert Tong : je ne vois pas de mention du contexte immédiat...
• Richard Smith : nous avons accidentellement ouvert la porte pour « statement SFINAE » et « declaration SFINAE » du fait qu'une λ peut apparaître à ces endroits, mais c'est un dossier pour le futur, et la TS sur les concepts vise C++ 14
• Faisal Vali : dans le cas du paragraphe 4, une note montrerait que ce n'est pas un accident, que c'est un truc auquel on a réfléchi
• John Spicer : la note peut suffire si elle indique que les règles normales s'appliquent si nous ne sommes pas dans le contexte d'un template
• Hubert Tong : je pense aussi qu'une note serait utile, mais je l'associerais au paragraphe 7
• Davis Herring : celle au paragraphe 3 ne suffit pas?
• Walter E. Brown : je le ferai
• Mike Miller : la note sera-t-elle écrite ce soir?
• Hubert Tong : ça peut se faire
• Walter E. Brown : si vous pouviez me l'écrire, je produirai une nouvelle révision du document
• Mike Miller : rédigez la note ce soir et on la révisera demain

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

• Faisal Vali : la proposition couvre deux aspect. Elle vise entre autres à rendre la bibliothèque standard deduction guide-aware
• Faisal Vali : si npus avons un deduction guide explicite qui correspond à un autre qui serait implicitement généré, on souhaite que le guide explicite l'emporte
• Faisal Vali : les deduction guides explicites seraient identifiés comme tels et ne seraient utilisés que dans le contexte d'une initialisation directe
• Richard Smith : le contexte souhaité est d'appliquer les mêmes règles de déduction que pour les constructeurs, mais nous ne sommes pas parvenus à exprimer cette idée dans la terminologie
• Richard Smith : dans §13.3.1.8, nous devrions expliquer comment y arriver
• Faisal Vali : la terminologie dans la proposition ne rejoint pas celle dans le WD
• Richard Smith : le texte devrait probablement être placé avant les règles propres aux templates
• Faisal Vali : alors on entre dans l'overload set, mais le deduction guide se comporte comme un « bris d'égalité » si la déclaration qu'il décrit correspond aussi bien que les autres à ce qui est rencontré dans le code
• Mike Miller : que doit-on comprendre de cette discusion?
• Faisal Vali : je vais aller à la rencontre de Mike Spertus pour reformuler la partie décrivant les règles de bris d'égalité. Nous verrons alors s'il nous est possible de revenir cette semaine
• Richard Smith : plus rapidement nous résolverons ceci et meilleur ce sera

Exception specifications

• Mike Miller : Alisdair Meredith m'a informé que les changements à faire sont viraux, alors je m'attends à ce que l'on ne revoit ce document que lors de la rencontre de Kona

US 72: unify std::byte and unsigned char

• Davis Herring : est-ce légitime de déposer un std::byte* dans un unsigned char* et l'utiliser?
• Richard Smith : oui. Après ça, ça devient subtil
• Richard Smith : nous pensons que les conversions de char ou d'unsigned char vers std::byte fonctionneront; dans l'autre sens, il faudra que std::launder() intervienne
• Hubert Tong : ça fonctionnera si on respecte les règles d'alignement
• Hubert Tong : en lien avec ce NB Comment, je pense qu'il est trop tard pour tout unifier. Par contre, du fait que le provision of storage est nouveau avec C++ 17, nous pouvons l'appliquer sélectivement
• Hubert Tong : je suis fortement en faveur d'une application locale
• Mike Miller : quelle est notre position?
• Hubert Tong : si un tableau d'unsigned char est trouvé dans un union, alors actuellement, le traitement de ce tableau devient extrêmement pessimiste...
• Richard Smith : l'incohérence de notre position me semble de mauvais goût
• Hubert Tong : il y a beaucoup d'incohérence sur ce plan déjà
• Richard Smith : nous pourrions déprécier le recours à char...
• John Spicer : ce serait une cassure importante avec C (il y aurait de la résistance, c'est le moins qu'on puisse dire). Un jour peut-être, mais pas maintenant
• Davis Herring : le fait qu'il n'y ait pas de consensus pour le changement me semble un peu strict
• John Spicer : quel serait le changement?
• Jason Merrill : du fait que ce soit du nouveau, ça ne me dérange pas trop
• Richard Smith : une orientation future pourrait être de changer nos pratiques quant à l'entreposage
• Dinka Ranns : sommes-nous le bon groupe pour discuter de ceci?
• Davis Herring : ce NB Comment est-il destiné à EWG?
• Richard Smith : déprécier unsigned char pour le remplacer par std::byte pour fins d'entreposage me semble tomber dans le créneau d'EWG
• John Spicer : nous devons couvrir le code qui existe déjà aujourd'hui
• Hubert Tong : au moins un compilateur utilise char plutôt qu'unsigned char aujourd'hui
• Richard Smith : si on disqualifie char ou unsigned char comme entreposage, je ne suis en faveur que si ça devient notre position officielle
• Dinka : nous sommes tous d'accord pour utiliser std::byte
• Hubert Tong : je suis d'accord avec std::byte, mais je veux déprécier unsigned char pour cet usage
• Mike Miller : ouvrons un Core Issue pour la dépréciation de char ou unsigned char. Accepté avec modifications
• Davis Herring : en C++ 14, il n'y a pas de règles spéciales pour utiliser unsigned char dans l'entreposage, et on a une implémentation qui triche et prend char. L'ajout de std::byte pour fins de remplacement suggère une intention de dépréciation
• Mike Miller : il n'y a pas de consensus clair. Rejeté?
• John Spicer : non, je pense qu'on a consensus pour ajouter std::byte
• Richard Smith : la question est de savoir avec combien d'enthousiasme
• Jens Maurer : la Core Issue pour déprécier les caractéristiques spéciales de char, peu importe la forme ou la couleur, sera ouverte en fonction du futur.
• Mike Miller : sommes-nous en faveur d'ajouter std::byte aux types utilisés pour fins d'entreposage? (unanime)
• Mike Miller : pour la dépréciation, on en rediscutera. Ça touche deux ou trois groupes d'intérêt

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

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

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

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

LWG active issue 2770

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

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

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

P0076R3: Vector and Wavefront Policies

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

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

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

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

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

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

• Peut-on utiliser les fonctions (quand elles existent) dans d'autres contextes, par exemple en prenant leur adresse?
• Si une classe dérive d'une classe implémentant tous les opérateurs relationnels, et si elle spécialise certains d'entre eux, synthétisera-t-on les autres ou utilisera-t-on ceux du parent?
• Y a-t-il une nuance comportementale entre la notation « opérateur » et la notation « fonction »?
• Supporte-t-on les Three-Way Comparisons?
• Quelles sont les contraintes imposées sur le type de retour de ces opérateurs? Peut-on par exemple retourner un entier qui indiquerait entre autres la distance entre deux objets?

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

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

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

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

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

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

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

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

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

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

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

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

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

D0270: Questions

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

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

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

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

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

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

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

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

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

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

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

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

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

Hans Boehm sera informé des retouches à faire.

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

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

GB 26: 'last' active handler and multithreading

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

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

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

GB 26: 'last' active handler and multithreading

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

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

Ça passera au vote vendredi en tant que DR.

GB 27: multiple activations of the same exception object

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

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

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

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

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

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

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

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

Resolved Module TS (N4610) Issues

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

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

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

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

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

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

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

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

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

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

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

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

Class Template Argument Deduction Assorted NB resolution and issues

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

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

Modules

• Mike Miller : dans le cas des modules, j'aimerais mieux comprendre la nature des problèmes
• Mike Miller : ma compréhension est que John Spicer souhaite des précisions quant à certains détails qui semblent sous-spécifiés dans les modules, alors que Gabriel Dos Reis souhaite comprendre comment ces détails pourraient être exprimer dans le contexte de ce que les modules peuvent offrir
• John Spicer : à mon avis, que Jonathan Caves travaille avec Gabriel Dos Reis suffira à régler le problème
• Mike Miller : malheureusement, Jonathan Caves est malade et ne reviendra pas aujourd'hui
• John Spicer : je pense que ces changements ont été demandés à Kona et n'ont pas encore été appliqués
• Mike Miller : pourrait-on obtenir une description des problèmes en mots plutôt qu'en code?
• John Spicer : je ne pense pas. Il nous faut des spécifications expliquant comment les templates interagissent avec les modules. Je ne vois pas comment exprimer des problèmes sans code
• Richard Smith : c'est un problème. Je sais quelles règles j'ai implémenté, mais je ne sais pas ce qu'elles sont supposées être
• Hubert Tong : dans les TS, ces règles sont parfois un peu floues
• Jason Merrill : notre expérience avec les concepts me rend méfiant pour ce qui est Core Stuff dans un TS
• John Spicer : qu'il y ait des irritants mineurs de ne dérange pas, mais je suis préoccupé par les irritants majeurs
• Davis Herring : est-ce un problème procédural
• John Spicer : non, c'est un cas de spécification manquante
• Mike Miller : à propos des concepts, nous sommes les responsables de la terminologie désormais
• John Spicer : ces derniers temps, nos efforts ont surtout porté sur la livraison de C++ 17
• Mike Miller : ma compréhension est qu'il y a perception d'un fossé ici, alors n'allons pas plus loin pour le moment
• John Spicer : je ne sais pas ce qui fait que les problèmes de spécification reviennent de manière récurrente dans ce cas
• Mike Miller : devrions-nous demander une session conjointe CWG-EWG?
• John Spicer : je laisserais Jonathan Caves et Gabriel Dos Reis travailler d'abord.

D0512R0: Class Template Argument Deduction Assorted NB resolution and issues

• Faisal Vali : j'ai ajouté au Wiki une version plus récente qui ne dépend pas de std::decay
• Richard Smith : dans la première modification, nous devrions indiquer « function template specialization » ou encore « F1 is generated from the template deduction guide »
• Richard Smith : une fois ce changement appliqué, on pourra le déplacer entre §1.5 et §1.6
• Jason Merrill : dans l'exemple sur les forwarding references, je ne pense pas qu'on ait besoin des mots « transformed into »
• Richard Smith : dans le dernier bloc de modifications, exemple à la fin du document, faudrait supprimer « Now add deduction guides, but "switch" explicit-ness » qui semble excessif. Le code qui suit décrit bien ce qui se passe
• Thomas Köppe : dans le premier changement, on voit le commentaire « initialized with #1 ». Ça devrait être #2 , non?
• Faisal Vali : non, à cet endroit, T est A<int>
• Davis Herring : il y a une erreur typographique dans l'abstract, mais c'est trivial et je l'aime!
• Faisal Vali : quand on utilise un mécanisme comme celui-ci autant que je l'ai fait, on a le droit de lui donner un surnom
• Faisal Vali : j'ai ajouté un exemple en fin de document en réponse aux questions d'EWG à propos des deduction guides pour des classes dans lesquelles on trouve des alias de types
• John Spicer : §14.8.2.1p3, la terminologie demande à être retouchée
• Faisal Vali corrige le tout
• Richard Smith : page 4, une puce antérieure réfère à une puce ultérieure
• Faisal Vali corrige le tout
• Richard Smith : page 4, devons-nous dire « T&& is not a forwarding reference during class template argument deduction »?
• Jason Merrill : une telle chose n'existe pas
• Faisal Vali corrige le tout
• (on fait plusieurs changements mineurs)
• Mike Miller : on votera ça vendredi

D0003R5: Removing Deprecated Exception Specifications from C++17

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

P0266R2: Lifting Restrictions on requires-Expressions

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

On l'envoie pour vote vendredi.

D0315R2: Lambdas in unevaluated contexts

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

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

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

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

Richard Smith : aucune idée.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1565. Copy elision and lifetime of initializer_list underlying array

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

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

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

1924. Definition of "literal" and kinds of literals

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

1721. Diagnosing ODR violations for static data members

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

2187. Protected members and access via qualified-id

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

2188. empty-declaration ambiguity

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

2189. Surrogate call template

Jason Merrill explique :

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

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

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

2190. Insufficient specification of __has_include

Hubert Tong indique que ceci :

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

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

2174. Unclear rules for friend definitions in templates

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

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

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

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

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

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

Core Issue 1721: Diagnosing ODR violations for static data members

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

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

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

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

GB 26: 'last' active handler and multithreading

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

DR: Matching of template template-arguments excludes compatible templates

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

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

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

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

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

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

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

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

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

D0298R2: A byte type definition

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

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

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

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

Editorial 522: [basic.life] Fix Modal Verb

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

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

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

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

Core Issue 1622: Empty aggregate initializer for union

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

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

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

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

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

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

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

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

Removing Deprecated Exception Specifications from C++17

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

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

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

Core Issue 1677: Constant initialization via aggregate initialization

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

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

On la présentera formellement à Kona.

P0329R2: Designated Initialization Wording

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

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

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

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

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

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

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

Clark Nelson : SG10 ne s'est pas rencontré

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

CWG Motions

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

Unanime

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

Unanime

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

Unanime

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

Unanime

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

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

Unanime

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

Unanime

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

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

Unanime

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

Unanime

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

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

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

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

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

Unanime

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

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

Consensus.

LWG Motions

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

Consensus

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

Unanime

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

Unanime

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

Unanime

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

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

Unanime

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

Unanime

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

Unanime

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

Consensus

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

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

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

Unanime

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

Unanime

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

Unanime

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

Unanime

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

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

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

Unanime

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

Unanime

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

Unanime

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

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

Unanime

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

Unanime

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

Unanime

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

Unanime

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

Unanime

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

Unanime

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

Unanime

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

Unanime

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

Consensus

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

Unanime

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

Unanime

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

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

Unanime

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

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

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

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

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

Ceci devrait-il compiler?

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

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

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

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

Core issue 2194: Impossible case in list initialization

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

Core issue 2195: Unsolicited reading of trailing volatile members

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

2196. Zero-initialization with virtual base classes

Avec ce code :

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

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

2197. Overload resolution and deleted special member functions

Cet Issue est d'ordre terminologique. Éditorial.

2198. Linkage of enumerators

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

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

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

2199. Typedefs and tags

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

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

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

• When performing lookup for a name in an elaborated-type-specifier, a class or enumeration declaration hides a typedef declaration that declares the same type
• In all other lookups, a typedef declaration hides a class or enumeration declaration that declares the same type

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

2200. Conversions in template argument deduction

Étant donné ceci :

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

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

2201. Cv-qualification of array types

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

2202. When does default argument instantiation occur?

Étant donné ceci :

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

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

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

2203. Defaulted copy/move constructors and UDCs

Soit ceci :

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

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

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

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

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

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

On escamote 2204, qui repose sur un malendendu.

2205. Restrictions on use of alignas

On a un exemple qui dit que ceci :

alignas(double) void f();

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

2206. Composite type of object and function pointers

Soit cet exemple :

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

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

2207. Alignment of allocation function return value

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

2211. Hiding by lambda captures and parameters

Qu'imprimera ceci?

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

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

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

2212. Typedef changing linkage after use

Oh boy. L'exemple motivateur est :

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

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

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

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

2213. Forward declaration of partial specializations

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

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

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

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

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

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

2214. Missing requirement on representation of integer values

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

Dans C11, on trouve plutôt :

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

2215. Redundant description of language linkage in function call

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

2216. Exception specifications in unevaluated contexts

Soit cet exemple :

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

Selon §15.4 p19 :

Mais il se trouve que :

sizeof(foo(0))

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

2217. constexpr constructors for non-literal types

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

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

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

2218. Ambiguity and namespace aliases

Les implémentations divergent sur ceci :

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

... mais pas sur cela :

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

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

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

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

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

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

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

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

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

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

2219. Dynamically-unreachable handlers

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

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

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

2220. Hiding index variable in range-based for

On se demande quoi faire avec ceci :

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

Jens Maurer s'en occupe

2221. Copying volatile objects

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

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

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

2224. Member subobjects and base-class casts

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

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

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

2225. reinterpret_cast to same floating-point type

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

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

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

2226. Xvalues vs lvalues in conditional expressions

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

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

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

2227. Destructor access and default member initializers

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

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

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

2228. Ambiguity resolution for cast to function type

Soit le code suivant :

int x = (int()) + 5;

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

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

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

2229. Volatile unnamed bit-fields

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

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

Ceci pose problème :

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

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

2231. Class member access to static data member template

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

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

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

2232. thread_local anonymous unions

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

2233. Function parameter packs following default arguments

Une proposition cherche à rendre ceci valide :

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

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

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

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

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

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

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

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

2235. Partial ordering and non-dependent types

Sois cet exemple de §14.8.2.5/11 

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

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

Pour un autre exemple :

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

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

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

2236. When is an alias template specialization dependent?

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

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

On va ajouter une note non-normative.

2237. Can a template-id name a constructor?

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

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

Heureusement, ceci semble illégal :

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

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

2238. Contradictory alignment requirements for allocation

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

2239. Sized deallocation with a trivial destructor

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

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

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

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

2241. Overload resolution is not invoked with a single function

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

2242. ODR violation with constant initialization possibly omitted

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

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

À réfléchir...