À propos de WG21, Lenexa 2015

Disclaimer

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

Début du contenu technique

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

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

Fin du contenu technique

Les sujets importants qui seront débattus aujourd'hui sont :

• Permettra-t-on d'utiliser des concepts partout, incluant dans les types de retour des fonctions ou en tant que type de variable dans une expression?
• Doit-on documenter la bibliothèque standard à partir de concepts dès C++ 17?
• Les clauses requires des concepts devraient-elles pouvoir être conditionnelles sur la base de clauses noexcept?
• Tous les concepts semblent être booléens, mais on exige malgré tout d'expliciter bool devant les concepts prédicats comme dans les concepts sous forme de variables. Ne devrait-on pas avoir une syntaxe spéciale pour réduire la quantité de texte redondant à écrire lors de l'expression de concepts?

Nous avons tout d'abord fait un survol rapide de tous les commentaires des quatre documents reçus, pour les catégoriser en fonction du traitement à leur accorder (traiter en CWG seulement, ou conjointement avec EWG, ou simplement remettre à l'éditeur du TS pour retouches mineures).

Les travaux ont suivi leur cours jusqu'à midi, à quel moment nous avons pris une pause. Nous avons eu le temps de traiter les commentaires canadiens, britanniques et une partie des commentaires finlandais pendant l'avant-midi.

En début d'après-midi, vers 13 h 30, nous avons repris les travaux dans une salle commune où se regroupaient les gens de CWG et d'EWG. L'idée est de voir ce qui regroupe les responsabilités des deux groupes de travail, en particulier pour ce qui est plus sujet à des débats plus rudes.

Après ces échanges, nous sommes retournés dans une salle à part pour compléter les travaux tombant sous la « seule » responsabilité de CWG. Nous avons fini d'éplucher les commentaires finlandais et américains. Certaines questions subtiles devaient aussi être débattues, comme par exemple : une clause requires{...} où les expressions entre { et } évaluent toutes à faux de manière démontrable mène-t-elle à un programme mal formé? Comment exprimer clairement la distinction entre les contraintes des concepts et les expressions booléennes qui s'y retrouvent?

Par la suite, la question est celle des suites :

• Recommandera-t-on de « pousser » le TS des concepts pour publication rapide?
• Tiendra-t-on des télé-rencontres (probablement deux) entre maintenant et Kona pour réviser les changements terminologiques, puis pousser le TS pour publication par la suite?
• Attendra-t-on à Kona pour voter collectivement sur le TS?

Gabriel Dos Reis nous laisse entendre que Kona sera une rencontre très chargée, et dit qu'on en saura plus à la rencontre de ce soir.

Nous souhaitions ensuite discuter de mémoire transactionnelle mais Jens Maurer a dû nous quitter, et sa présence nous semblait essentielle. Nous avons donc profité du moment pour aborder des questions grammaticales et terminologiques, comme par exemple : quel nom donner aux fonctions comme les constructeurs, destructeurs et opérateurs de conversion, qui ont une syntaxe différente des autres? Et comment exprimer cette différence de manière non-ambiguë?

Pour la mémoire transactionnelle, le document discuté est http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4302.pdf. Les commentaires sont rassemblés dans http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4396.pdf, et le feedback de Jens Maurer se trouve dans http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4410.html.

Les suggestions et commentaires sont traités un à un, et les résolutions suivent pour la plupart ce qui découle de l'analyse de Jens Maurer. Dans certains cas, on recommande de faire suivre les recommandations à LWG pour s'assurer qu'ils soient confortables aussi puisque ça les touche. Dans d'autres cas, comme le changement d'un mot clé hypothétique (de transaction_safe_noinherit à transaction_safe_dynamic), on relaie la recommandation à EWG. Notez que le choix d'un mot clé ne rencontre presque jamais l'assentiment de tous; c'est un truc périlleux, avec lequel il faudra vivre longtemps.

La mémoire transactionnelle est un sujet subtil, qui touche à la question de savoir ce qui peut être déterminé quant à l'ordonnancement des opérations dans un programme parallèle ou concurrent sur la base de son texte. Par exemple, certains libellés laissent entendre qu'il soit possible de déterminer une relation happens-before entre deux instructions situées dans deux blocs distincts s'exécutant concurremment; cela va de soi dans un même thread, mais sinon cela suppose un hypothétique ordonnancement total entre plusieurs threads ce qui est beaucoup moins évident. Pour cette raison, certaines résolutions causent un léger inconfort, mais rien de suffisant pour bloquer l'avancement du dossier.

Dans certains dossiers nouveaux ou expérimentaux, comme celui de la mémoire transactionnelle ou celui des concepts, le support des nouvelles fonctionnalités peut typiquement être validé par des directives d'inclusion conditionnelle, ce qui implique la standardisation de macros pour indiquer le support ou non de chaque fonctionnalité, sur une base individuelle, et de valeurs (numériques, avec croissance monotone) associées à ces macros pour permettre une forme de contrôle des versions. Le choix de ces macros, de même que leur présentation dans les documents comme les TS (car ce qui est standard est supposé être supporté, point à la ligne, alors que les TS peuvent l'être ou non pendant une période d'essai) demande un effort de formalisme et de cohérence entre les documents. Pour cette raison, nous discutons un peu avec Clark Nelson, le chairman de WG21.

Deux de mes propositions sont acceptées de facto. Une autre (question de clarification terminologique) est refusée, ce qui est correct. Moment amusant : l'un des individus, voyant ce document, passe une remarque sur ces idiots d'universitaires qui ne comprennent rien, ce à quoi je me suis permis de répliquer « en passant, l'idiot d'universitaire, ici, ce serait moi ». Disons que ça a détendu l'atmosphère

Parfois, des trucs subtils surgissent. J'avais souligné l'impossibilité d'écrire un swap() qui serait Transaction-Safe avec l'écriture courante car std::move(), comme plusieurs autres fonctions « utilitaires » du genre, n'était pas considéré Transaction-Safe. On avait généralisé mon commentaire pour couvrir l'ensemble des fonctions utilitairs, mais Alisdair Meredith a allumé ce matin que l'on couvrait aussi declval<T>() avec cette recommandation, or cette fonction ne sert que dans un contexte statique (elle n'est jamais appelée) ce qui rend impertinent le fait que la rendre Transaction-Safe, les transactions étant un mécanisme foncièrement dynamique.

Autres trucs subtils :

• Que se passe-t-il avec l'initialisation d'une variable statique dans une transaction qui échouerait?
• Quel est le coût de la synchronisation d'un thread sans transaction compétitionnant avec un thread transactionnel si les deux sont susceptibles d'initialiser une variable statique?

Ensuite, nous avons discuté de plusieurs sujets subtils mais pointus, découlant de remarques soumises par des gens ayant « frappé des noeuds » dans le standard (incohérences, trucs obscurs, ambiguïtés, etc.). Selon l'écriture du standard telle que nous l'avons avec C++ 14 :

L'expression new(nothrow)int[N] pourrait lever une exception convertible en bad_array_new_length si N est incorrect. La phrase est complexe, alors on travaille sur la lisibilité

Le standard utilise parfois les expressions happened-after et sequenced-after mais ne définit que les expressions happened-before et sequenced-before, plus près de la littérature. Une option est de reformuler les diverses occurrences de ...-after en ...-before, mais c'est périlleux et il y en a beaucoup. Nous allons plutôt dans le sens de donner un sens formel à ...-after, sur la base de ...-before par souci de cohérence. On a sûrement manqué des cas de spécification d'ordonnancement dans le standard, mais étant donné l'ampleur de la tâche, il est sans doute préférable d'attendre que certains remarquent des irritants avant de s'investir dans un passage du texte de près de 2000 pages au peigne fin

Cas très subtil : comment identifier la conversion appropriée vers un type commun dans un cas d'opérateur ternaire (forme expr ? a : b) tout en tenant compte des diverses formes de références et des trucs obscurs comme les bitfields. Le standard ne semble pas couvrir correctement les cas que l'imagination des programmeuses et des programmeurs a pu faire surgir, mais ce que nous avons sur la table ne satisfait pas non plus. On va continuer de travailler sur celle-là.

Truc obscur mais qu'il faut gérer : les spécifications d'exceptions sur les expressions λ (dépréciées mais pas disparues).

Autre truc obscur : la possibilité de faire des macros qui bousillieraient les directives #include. C'est un irritant auquel C fait aussi face.

Truc obscène : écrire des fonctions ou des constructeurs constexpr mais dans lesquels interviennent des éléments variants mutables. Sans commentaires. Faut trouver une formule pour dire non.

Discussion sur la proposition http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4430.html par Richard Smith, sur la nature des pointeurs et des pointés, et le lien entre pointeur et objet (au sens C++ du terme).

On a quatre cas :

• Pointeur sur un objet
• Pointeur juste après un objet, p. ex. :

X x;
auto p = &x;
auto q = &x+1; // p pointe sur l'objet, q pointe juste après l'objet

• Pointeur invalide, p. ex. :

auto p = new X;
delete p; // suite à la destruction de *p, p est invalide

• Pointeur nul d'un certain type, p. ex. : X *p = nullptr;

Nous avons débattu de questions subtiles comme : après la mort d'un objet, peut-on encore dire que le pointeur y pointant pointe sur un objet? Selon Richard Smith, la réponse est oui, mais sur un objet dont la vie est terminée.

La mémoire brute devrait apparaître comme un tableau d'unsigned char pour permettre l'arithmétique de pointeurs.

La vie d'un objet débute quand ses attributs sont tous initialisés. Cela dit, quand débute la vie d'un union? Ce n'est pas évident puisque certaines parties peuvent ne pas être initialisés. Richard Smith propose que l'affectation d'une valeur à un membre d'un union fasse de ce membre le membre « actif » de l'union. C'est important pour les cas où on passerait l'adresse d'un membre de l'union à une fonction, ou pire : dans le cas où un comique passerait l'adresse de deux membres distincts d'un même union à une fonction, genre :

union U
{
   int i;
   char c;
};
void f(int&, char&);
int main()
{
   U u;
   // ...
   f(u.i, u.c); // duh???
}

Ouch! La détermination du membre « actif » de l'union iintervient aussi pendant sa construction, s'il y a lieu.

Avec cette proposition, retourner un pointeur sur une variable locale deviendrait un retour d'un pointeur invalide, formellement, ce qui deviendrait utile sur le plan des diagnostics. Jens Maurer fait remarquer que l'optimisation Copy Elision contournerait cette nouvelle considération en enlevant la copie du portrait (ouch!), mais on peut toujours décider de ne pas appliquer cette optimisation dans le cas où le pointeur retourné par copie serait invalide.

La proposition formalise aussi des trucs comme :

struct X
{
   int m;
};
int main()
{
   X x;
   assert((void*)&x==(void*)&x.m); // Ok
   reinterpret_cast<int*>(&x); // incorrect
}

... ou encore comme :

union U
{
   int i;
   char c;
};
int main()
{
   U u;
   assert((void*)&u.c == (void*)&u.i); // Ok
   reinterpret_cast<int*>(&u.c); // incorrect
}

Richard Smith introduit la fonction std::launder() pour obtenir un pointeur distinct sur un pointeur existant. C'est pervers, et faudra la passer à LEWG, celle-là (le gag, c'est d'essayer d'imaginer leur réaction ). L'idée ici est de permettre les malpropretés (explicites) comme ce qui suit, quand quelqu'un sait vraiment ce qu'il fait. L'exemple et les commentaires sont tous de Richard Smith :

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

C'est sûrement l'un des trucs les plus intéressants, mais les plus pervers, que j'aie rencontré jusqu'ici cette semaine. On pourrait entre autres utiliser launder() pour implémenter optional<T>, dont j'ai une version maison (non-commerciale) avec maybe<T>, en utilisant à l'interne l'expression :

*launder(reinterpret_cast<T*>(&buf[0]))

... pour traiter buf, un unsigned char[sizeof(T)], comme un T&, mais ceci :

union // anonyme, c'est volontaire
{
   T obj;
   char buf[sizeof(T)];
};

...est préférable pour faciliter le recours à constexpr.

Question ouverte : devrait-on ajouter un launder() implicite à reinterpret_cast? Je pense aux fonctions du système d'exploitation qui passent par un void* ici. On réfléchit... C'est pas propre, c'est déjà illégal (même si personne ne le sait et même si ça tend à passer pareil). Quelle est la pratique qu'on veut encourager ici?

Jonathan Caves parle de launder() comme « hey, le compilateur, ferme donc tes yeux pour une seconde ». On rigole un peu.

On passe ensuite à la clarification du sens à donner à des expressions impliquant void ou void* avec qualifications cv. Ça peut arriver avec des conversions à void dans des expressions comme (void)a,b par exemple, comme on en voit dans certaines implémentations de la STL pour contourner des pièges tendus par des gens qui auraient surchargé l'opérateur ,.

On jase sur la possibilité de distinguer void f(void) et void f(const void), mais semble qu'aucun compilateur connu ne supporte cette horreur.

Richard Smith dit qu'on lui aurait laissé entendre que la déclaration extern void x; serait légale. Hubert Tong indique que oui, en C); si on ne la définit pas, c'est une déclaration sans définition, ce qui devient un bris (inverse) d'ODR.

Ensuite, examen de la question de la durée de vie des références. Quelques retouches à faire : un bout de texte qui parle de l'espace occupé par une référence (une référence, techniquement, n'est pas un objet et n'occupe pas d'espace). Aussi, la question de la fin de la vie d'une référence, ce qui peut jouer dans certains cas limites comme la fin d'un objet contenant des références : selon que le destructeur soit trivial ou non, l'ordre de destruction des membres n'offrira pas les mêmes garanties.

À quel moment passer par une référence menant vers un objet décédé devient-il un cas de comportement indéfini? On a des cas comme :

struct X
{
   int i;
   constexpr X(int i)
      : i{i}
   {
   }
};
constexpr X x{3};
X &r = x;
new (static_cast<void*>(&x)) X{4}; // effet sur la vie de r?

On revient sur la terminologie des concepts, pour le passage définissant at least as constrained as qui posait problème selon l'analyse de Botond Ballo. On l'envoie à Andrew Sutton pour intégration au TS.

On a ensuite un cas d'ajustement terminologique à l'utilisation de type ODR-use d'une fonction virtuelle qui serait =delete, pour éviter qu'un ODR-use implicite soit une référence à cette fonction et fasse échouer la compilation. On constate au passage qu'il faut réserver un espace dans la vtbl pour la fonction même si elle est supprimée.

Un dossier mineur mais amusant : clarifier le fait qu'atteindre la fin d'une fonction non-void sans retourner quelque chose est un comportement indéfini. La question qui tue est le traitement de main(), cas unique qui a un return implicite d'un code de succès mais est int; on s'en sort par la distinction entre reaching the end of main() et flowing off the end of a function.

Après quelques trucs pour alléger l'écriture de certains passages du standard sans altérer l'intention, on parle des cas de Copy Elision dans un une expression constexpr.

On a un cas pervers d'un objet avec invariants cachés, initialisé à la construction sur une base constexpr :

struct A
{
   void *p;
   constexpr A()
      : p(this)
   {
   }
};
constexpr A a; // well-formed : a.p == (void*)&a
constexpr A b = A{};  // peut être mal formé sans Copy Elision: b.p peut pointer sur une temporaire

Amusant mais douloureux : on a un cas ou T a = T(); et T a{}; ne donnent pas nécessairement la même chose! Notre choix immédiat a été d'accepter ceci, mais plus tard dans l'après-midi (je fais un saut dans le temps ici), Gabriel Dos Reis et Daniel Krügler ont réagi par écrit en se disant surpris de notre position. C'est vrai que c'est un peu weird, mais Copy Elision est optionnel alors il vaut mieux ne pas écrire du code qui en dépende.

Richard Smith lance en quasi-boutade que Copy Elision est l'optimisation que nous faisons mais qui n'est pas as-if, donc qui a un effet observable sur la sémantique d'un programme.

On se demande s'il serait préférable de donner dans le « pas de Copy Elision dans un contexte constexpr », puisque le résultat de l'initialisation est résolu à la compilation de toute manière. On essaie de voir les conséquences, par exemple dans des expressions ternaires. Finalement, ma compréhension est que la copie sera obligatoire dans ce cas. Morale de cette histoire : ne pas écrire de code sémantiquement dépendant de Copy Elision.

Autre dossier complexe, celui de l'initialisation à zéro pour les variables statiques et les variables Thread-Local. Beaucoup de travail d'écriture ici. On remarque qu'une variable static locale à une fonction, si sa construction lève une exception, n'a pas été construite et la construction sera ré-essayée au prochain appel.

Pour les variables Thread-Local, on cherche une terminologie qui permettra l'efficacité maximale d'initialisation selon l'implémentation, car dans certains cas il est préférable d'initialiser à zéro au démarrage alors que dans d'autres cas, l'essentiel est de le faire avant la première utilisation.

On a des perversions possibles comme une fonction retournant par decltype(auto) une λ sans capture qui, pour sa part, retourne l'adresse d'une variable globale thread_local.

Que faire quand on charge une bibliothèque à liens dynamiques? On vise un as-if ici qui éliminera les différences observables entre initialisation statique et Thread-Local tout en permettant d'être efficaces selon les choix d'implémentation. Une des difficultés que nous avons est que les divers modes d'initialisation (dynamique, statique, Thread-Local) ne sont pas regroupés en un seul endroit, alors il faut s'éparpiller un peu et assurer une forme de cohérence.

Exemple absolument pervers de Richard Smith :

auto f() {
  static int n = 123;
  struct X { int &f() { return n; } };
  return X();
}
int &r = decltype(f())().f();

Sans commentaire.

Enfin, on parle d'alignement, plus précisément de multiples clauses alignas et des conséquences de possibles demandes incorrectes, comme on pourrait l'avoir avec une expression variadique.

Le cas alignas(0), qui est présentement considéré « sans effet », pourrait être simplement not well-formed.

C'est pas simple de déterminer la bonne formule : si on a deux alignements et si l'un des deux est trop « mou » alors que l'autre est suffisamment strict, devrait-on ignorer le mou ou rejeter l'expression?

On examine d'abord Parameter Stringization, par Robert Douglas.

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

On parle de réflexivité, d'une manière visible à même la signature des fonctions. Robert Douglas utilise @ pour qualifier ses paramètres (capture à la pièce), mais c'est à titre indicatif. Il qualifie ses fonctions par reflect entre la parenthèse fermante et l'accolade ouvrante. Un truc comme

template <class T, class U>
   void f(T t, U u) reflect
   {
      auto s = f.param<0>().as_string();
   }

...ferait de s une version string du paramètre t. On s'inspire clairement des std::tuple ici.

Robert Douglas parle aussi d'un service source_context() qui donnerait accès aux numéros de lignes, au nom de la fonction, ce genre de truc. Il souhaite éliminer les macros comme __FILE__ ou __FUNCTION__.

Une autre variante serait d'ajouter un paramètre avec valeur par défaut à la signature des fonctions (un std ::reflect_stuff, genre).

On a plusieurs questions ouvertes. Entre autres, la proposition propose de « stringifier » les éléments mais on ne voit pas clairement comment utiliser d'autres types que std::string pour y arriver.

Le recours à @ ne passe pas bien. J'entends don't mess with the types dans la salle. L'approche qui prend en paramètre un reflect_stuff semble plus flexible à mes yeux. C'est bien reçu, mais un membre dans l'assistance est fortement contre (la possibilité de surcharger le paramètre lui semble une aberration); ce membre préfère la version avec mot clé reflect qualifiant la fonction.

On examine ensuite Source-Information Captures Extensions, par Robert Douglas.

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

Cette proposition amène un objet représentant un point dans un fichier, pour remplacer les macros. Évidemment, on parle de trucs constexpr ici.

Truc amusant : on a voté, c'était relativement favorable, mais Chandler Carruth a mis son chapeau de « gars de compilateur » pour le vote et a dit que ça ralentirait le compilateur et qu'il se battra jusqu'à la fin pour empêcher ceci d'être intégré au standard. Ensuite, il a encouragé le présentateur à continuer... Ah, la vie à WG21!

Il y a de la résistance semblable à d'autres volets de la proposition. Quelqu'un soulève la question du support optionnel de cette mécanique : si on ne veut pas ralentir la compilation, alors n'utilisons pas ces facilités, tout simplement. Ça semble raisonnable, mais Chandler Carruth indique que l'on manque d'expérience concrète pour avoir la capacité de poser un jugement raisonnable.

Alisdair Meredith pense aussi que l'idée est chouette mais que des données empiriques sont requises pour être en mesure de poser un jugement raisonnable. Chandler Carruth dit que pour faire de vrais bons tests, faudrait créer des fichiers pathologiquement méchants et voir ce que ça donne.

On y reviendra quand on aura des données et quand on sera plus en mesure de juger des conséquences.

Ensuite, Defining Test Code, par Robert Douglas et Michael Price

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

Comment marquer le code qui ne devrait servir qu'à fins de test? Pourrait-on le faire par des attributs ou des mots clés plutôt que par des macros? Leur syntaxe est :

int main() test
{
   f();
}

...qui appellerait void f() test; mais pas void f();. Ils parlent de code « atteignable » ou non à partir d'un certain point. On ne peut pas utiliser des annotations ici car celles-ci ne sont supportées que de manière optionnelle.

Une fonction marquée test pourrait appeler une fonction non-test mais pas l'inverse.

J'ai de grosses réserves ici; je crains que ça ne dérape en spaghetti de cas particuliers.

Chandler Carruth fait un rappel à l'ordre, au sens où on est un peu hors-sujet dans un forum sur la réflexivité. En généralisant le propos, par contre, c'est autre chose. Faudra voir.

On examine alors Static Reflection, par Matus Chochlik (il me manque des accents ici), présenté par un tiers qui en aime le contenu.

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

C'est un gros document, ≈75 pages, mais qui peut être segmenté et adopté de manière modulaire.

La clé : l'opérateur statique mirrored(T) retourne un type « sans nom » qui décrit T, puis des traits sont applicables sur ce type pour raisonner à son sujet dès la compilation. Ces traits décrivent les « concepts » implémentés par T (les « concepts » sont entre guillemets parce que c'est le nom choisi par l'auteur, mais le présentateur n'est pas convaincu que l'on parle ici de la même chose que l'idée de concept tel qu'envisagé pour C++ 17). Par exemple, si mirrored(N::C) est T, alors meta::scope<T>::type est N car C est un sous-type de N.

Chandler Carruth indique que mirrored(T), tel qu'exprimé, pourrait fonctionner sur des templates et sur des types incomplets. Quelques éléments ont été enlevés de la proposition générale pour qu'on puisse digérer ce que l'auteur met de l'avant. On aura, avec cette proposition, des trucs comme la liste des constantes énumérées d'un type et autres trucs sympas. Cette proposition couvre aussi le cas des espaces nommés.

Chandler Carruth dit que la proposition originale comprend aussi un opérateur reified(U) pour complémenter mirrored(T) de telle sorte que (essentiellement) std::is_same<reified(mirrored(T)),T>::value s'avère.

Pouvoir faire de la sérialisation sur la base de la réflexivité semble être une préoccupation pour bien des gens. Le vote met en relief que les membres du comité souhaitent pouvoir faire de la réflexivité sur des typedef. La capacité de réflexivité sur des templates et leurs caractéristiques sans nécessairement les instancier a aussi attiré un intérêt, mais moindre. Chandler Carruth est contre car il ne souhaite pas permettre d'observer l'ordre d'instanciation des templates. La notation sur la base d'opérateurs ne rencontre pas de résistance.

Enfin, on a From a type T, gather members name and type information, via variadic template expansion, par Cleiton Santoia Silva.

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

Le pauvre Cleiton Santoia Silva n'a que dix minutes pour presenter... Il propose :

• La forme typedef<T> qui donne un std::tuple des adresses des membres de T
• La forme typedef<T, is_enum> pour is_enum<class> un prédicat statique
• La forme typeid<T> qui donne un std::tuple des noms des membres de T

C'est flexible! Ça permet quelque chose comme :

auto s = { typedef<X,is_setter> }; // initializer_list!

On n'a pas donné à Cleiton le temps requis pour exprimer ses idées. Heureusement, son approche basée sur des foncteurs statiques a été bien reçue. Certains (Hubert Tong par exemple) favorisent une approche plus « langage », mais moi j'aime bien la vision métaprogrammée que Cleiton met de l'avant.

On commence vers 8 h 45

Retour par un des membres sur des échanges hier soir portant sur la terminologie pour les Feature Test Macros (un court texte disant que ça existe, puis un table nom/valeur).

Petit retour sur une retouche terminologique en lien avec ces macros. Ça va revenir à plusieurs TS qui seront votés vendredi. On va aussi recommander de pousser le TS de mémoire transactionnelle vendredi sur lequel on pourra voter.

Hubert Tong revient avec une formulation pour le problème dont nous avions discuté hier soir lui et moi et portant sur une ambiguïté grammaticale dans certaines utilisations de constructeurs. On travaille fort pour éviter que les changements grammaticaux proposés de permettent pas d'écrire des aberrations et ne fassent qu'atteindre leurs objectifs. On ne termine pas sur-le-champ (c'est subtil).

On revient sur la question de Copy Elision dans un contexte constexpr. Hubert Tong fait remarquer que la question s'applique aussi à l'initialisation de variables statiques. Richard Smith fait remarquer que dans une expression complexe, il pourrait arriver que l'on ait un traitement où les décisions prises antérieurement sur l'élision ou non soient renversées par l'interdit de réaliser l'élision pour des raisons contextuelles. Richard Smith mentionne aussi que certaines implémentations garantissent Copy Elision dans certaines circonstances; nous risquons de les briser ici.

Je fais remarquer que le débat ressemble beaucoup à celui des bris d'invariants cachés lors de mouvement implicite; Jonathan Caves dit que c'est de là que move_if_noexcept() était ressorti.

On se demande si on peut garantir la portabilité des sources dans une telle situation. Richard Smith rappelle que Copy Elision n'est pas as-if. Hubert Tong demande si on peut dire que le comportement est Implementation-Defined alors. Richard Smith estime que ce serait raisonnable. Jens Maurer dit qu'on pourrait demander à Gabriel Dos Reis s'il résiste toujours à notre position. Hubert Tong dit que plusieurs personnes écrivent du code qui n'a de sens qu'avec Copy Elision. Jens Maurer dit que c'est pas portable. Richard Smith  dit que ça arrive quand même.

On fait remarquer que les calculs statiques ne pourront plus être garantis comme donnant des résultats identiques aux calculs dynamiques, mais Jens Maurer rappelle qu'on ne le fait déjà pas pour les nombres à virgule flottante. Je penche pour Implementation-Defined : c'est pas portable, mais si t'as un seul compilateur dans ta vie, et si t'es à l'aise avec ses choix bien spécifiques, c'est ta vie.

On va y revenir, c'est pas réglé encore...

On revient sur la question de l'initialisation à zéro des variables static et thread_local. Jens Maurer a retravaillé la formulation. Le texte ratisse plus large et couvre l'initialisation statique des variables non-automatiques en général.

Hubert Tong demande si on devrait discuter des temporaires.

On travaille sur la formulation, particulièrement dans le cas des thread_local, pour être certains de dire ce qui doit vraiment être dit. Faire une bêtise ici changerait l'ordre d'initialisation des variables!

On examine aussi certains déplacements entre sections pour faciliter la compréhension, mais faut suivre de près les références croisées. On finit avec quelque chose de pas mal.

Vient ensuite sur la table un truc pas cool, soit que && est parfois valide dans un nom de type alors que ce ne l'était pas en C++ 03 (à cause des références sur des rvalue), ce qui permet de briser du code horrible comme :

bool b1 = new int && false; // previously false, now ill-formed
struct S { operator int(); };
bool b2 = &S::operator int && false; // previously false, now ill-formed

Oh boy... On ajoute une note dans une annexe de bris de compatibilité.

On parle ensuite de conversions contextuelles et du mot explicit. La terminologie dans un cas précis semble permettre d'appliquer une conversion explicit sur la base du contexte mais sans expliciter l'intention. On se demande si on devrait contraindre un peu plus et éliminer les conversions explicites du lot. On est pas mal d'accord.

Ensuite, on a une « simple » retouche pour dire qu'une λ non-générique sans capture convertie en fonction à l'aide d'un opérateur de conversion noexcept(true). On retouche le texte pour fins de conformité sans changer l'intention, mais faut valider les changements.

Après la pause, on revient sur le fait que les fonctions de conversion en fonctions globales de λ non-génériques stateless     devraient être non-throwing. Le cas des λ génériques est maintenant aussi couvert de manière analogue.

Décrire une fonction qui retourne une fonction et parler des particularités de chacune sans écrire de phrase ambiguë est un exercice de style complexe. On sépare en plus petites phrases.

On se demande si on devrait rende ces fonctions de conversion constexpr aussi. À voir; on en discutera avec EWG qui a un sujet semblable sur la table.

Ça finit par faire un texte complexe. L'air de rien, on a travaillé longtemps là-dessus.

Vient 1391 et la conversion de types de paramètres dans des arguments non-déduits. La formulation recherchée doit tenir compte des noms dépendants de types et du moment où l'on sait ce que ces noms signifient. Richard Smith questionne les moments dans le processus de compilation où certaines transformations et vérifications devront être faites. La proposition est bien faite et l'exemple est utile.

On revient aussi à nouveau sur l'ambiguïté grammaticale pour les constructeurs. La relecture est complexe (il y a une dizaine de clauses grammaticales en jeu). On simplifie un peu les libellés. Faut ensuite s'assurer que les nodeclspec-function-declaration n'apparaissent pas là où elles ne sont pas à propos (donc à quelques endroits seulement, dont les templates qui sont une grammaire à part entière). Hubert Tong a travaillé fort.

Un item est proposé par James Widman pour la syntaxe des initialisations entre accolades. La terminologie init-operand est mal reçue, alors on retravaille la terminologie pour en arriver à un truc comme expr-or-braced-init-list. Faut s'assurer que le tout s'intègre grammaticalement aussi dans les initialisations de répétitives for sur des intervalles. Richard Smith rapporte qu'on a un autre cas grammaticalement suspect à corriger. James Widman va prendre la balle au bond et poursuivre les travaux puisque l'idée est bien reçue.

Autre item proposé par James Widman et portant sur la définition des méthodes constexpr. On examine des considérations d'analyse en deux temps de certaines structures grammaticales, et une formalisation plus claire des déclarations a priori et des évaluations a posteriori. Ça touche des cas étranges comme :

struct X
{
   static constexpr std::size_t size()
   {
      return sizeof(X); // X is complete type
   }
   char arr[size()]; // is 'size' undefined here?
};
struct Y
{
   static constexpr int offset()
   {
      return offsetof(Y, c); // Y is complete type
   }
   char arr[offset()]; // is 'offset' undefined here?
   char c;
};
struct Z
{
   static constexpr int f()
      { return g(); }      // is 'g' defined here?
   static constexpr int g()
      { return 0; }
};

Hubert Tong craint qu'une même entité puisse être une déclaration a priori et ne pas l'être en même temps. Richard Smith fait remarquer que les valeurs par défaut des paramètres sont aussi des évaluations a posteriori.

Il semble qu'un manque de clarté sur ces points ait compliqué la vie de bien des gens. Ceci impact entre autres notre capacité d'appeler une méthode constexpr pour obtenir la taille d'un tableau à la compilation. Jens Maurer conteste le recours à forward-declared ici, qui ne sert pas vraiment dans le reste de la proposition; on trouve une alternative.

Hubert Tong demande comment évaluer la fin d'une région de code sans en analyser le contenu; semble qu'on y arrive en examinant la correspondance des accolades et des chevrons. On ne veut pas non plus casser le code C++ 98 avec l'écriture ici qui dicte l'ordre d'évaluation des trucs. En retour, on pourrait en arriver à une écriture par laquelle les classes et les class templates sont traitées de manière plus semblable. Jens Maurer recommande qu'on passe cette partie à EWG, car c'est substantiellement plus complexe.

On n'a pas de résolution, outre que l'ordonnancement restera non-spécifié. Une autre approche serait d'introduire des éléments grammaticaux indiquant où les choses se terminent, mais ça fait peur aux gens de compilateurs dans la salle (pour les trois principaux compilateurs).

À suivre...

On examine une demande qui cherche à clarifier le type de p dans :

void f(int a[10], decltype(a) *p);

... à savoir s'il devrait s'agit de int(*)[10] ou de int**.

Hubert Tong fait remarquer que la terminologie proposée, qui parle entre autres de type de retour, n'aide pas à clarifier la définition des constructeurs génériques. On ajoute des précisions. C'est une retouche importante, qui touche le nommage des paramètres dans les templates, alors ça prend du temps et du doigté.

On a un échange par la suite sur le fait qu'un exemple laisse entendre que sizeof(T) n'est pas équivalent à sizeof(T)+0, ce qui me laisse perplexe et lance une brève discussion sur la nuance entre « équivalent » et « fonctionnellement équivalent ». Cela rappelle des échanges avec Botond Ballo sur la nature de l'équivalence fonctionnelle dans les concepts, ces dernières semaines.

Truc agaçant : les trois principaux compilateurs traitent alignas(sizeof(T)) et alignas(sizeof(T)+0) comme étant équivalents, mais pas le standard. J'ai testé avec :

• msvc 2015 RC1
• g++ 4.8 (je pense) via http://coliru.stacked-crooked.com/
• clang 3.5.1 via http://gcc.godbolt.org/

Le problème est que l'équivalence ne tient compte que des noms, donc les compilateurs ont tort (c'est parce que le standard indique no diagnostics required). Mais ça agace d'autres gens, alors on cherche un meilleur terme que « équivalent », qui a un sens technique ici, pour éviter les aberrations. Richard Smith suggère d'y aller avec une définition contextuelle de l'équivalence, pour prendre en charge les cas de généricité (simple, double, …).

Un gros 75 minutes de travail ici, et on n'a pas fini.

Suit, le cas de l'item 1863 quant à ce qu'on exige d'un objet pris en charge par std::current_exception(). Le libellé actuel laisse entendre que l'objet doive être copiable. On précise ce qui est considéré odr-used dans un tel cas (ce qui est sélectionné l'est, que ce soit utilisé ou élidé en pratique).

Hubert Tong soumet le problème 2020 pour le cas étrange du sous-objet de delta zéro dans les requis du standard layout, dans un cas d'EBCO. Sa formulation est acceptée.

James Widman soumet 1247, un correctif mineur (suppression d'un passage irritant). Ok.

On attaque les cas de priorité de niveau 1. Nous avons couvert plus de cas que ceux listés ici, mais certains ont simplement été mis sur la glace le temps que nous puissions consulter les autres des soumissions.

Item 1584 : déduire un type de fonction sur un type générique cv, p. ex. :

void f() {}
template <class T> deduce(const T*){}
int main()
{
   deduce(f); // légal?
}

Ou encore ceci, qui provoque une récursion infinie :

template <typename T> struct tuple_size {};
template <typename T> struct tuple_size <T const>: tuple_size<T> {};
tuple_size <void()> t; // et c'est parti!!!

La résolution accompagnant le signalement du problème propose d'ignorer la qualification cv dans ce cas. L'avis du CWG est de l'interdire, carrément. C'est plus simple.

Item 1907 : ceci est-il bien formé?

void f(int, int);
template<typename T> void g(T t) { f(t); }
void f(int, int = 0);
void h() { g(0); }

C'est pas clair, évidemment. Si on se base sur les noms seulement, c'est Ok. On y reviendra.

Item 1928 : préciser ce qui est trivialement copiable. On a une opposition forte pour ce qui est de laisser l'accessibilité affecter la trivialité, comme le suggère https://isocpp.org/files/papers/n4148.html, mais si nous suivions les recommandations de cet article, nous aurions une trivialité selon le contexte d'utilisation, ce qui serait étrange. Hubert Tong craint que cela ne mène quelqu'un à essayer de profiter de « copiabilité triviale » des contextes inattendus. On va attendre pour celle-là aussi.

Item 1962 : le type de __func__ est-il un tableau de char ou un const char*? Le traitement varie selon les implémentations actuellement, même si le standard suggère static constexpr const char[]. Avec const char*, ça laisse moins de latitude pour faire varier les implémentations. De puis, si on traite __func__ comme un char[], alors passer __func__ à un truc comme

template<class T> void f(T&);

...donnera des résultats variant selon l'implémentation, et peut casser les ABI. Ça impacte 8.4.1 parag. 8.

On se demande si on devrait bloquer les gens qui veulent s'amuser à explorer __func__ avec des fonctions constexpr, et on décide de les laisser se faire plaisir.

Item 1965 : le plaisir de dynamic_cast et de static_cast sur des références entre parent et enfant. Présentement, le standard bloque un cas de static_cast d'une manière qui provoque une asymétrie discutable.

On s'interroge à savoir si on doit faire une manoeuvre semblable pour const_cast, on se demande pourquoi on le ferait, et Hubert Tong trouve un cas pas gentil qui rendrait ça utile.

Richard Smith indique qu'on peut implémenter, de manière surprenante, std::move() à l'aide de const_cast (à réfléchir).

On essaie d'éviter que const_cast ne puisse convertir un T&& en const T&.

Ce qui se passe quand T est un tableau est préoccupant : on ne veut pas que const_cast crée des temporaires comme le fait parfois static_cast. Le correctif amené cet après-midi semble avoir été suggéré par Hubert Tong et Michael Wong... il y a quelques années .

Item 1979 : un cas d'alias génériques...

template<typename T>
   struct A
   {
      struct B
      {
         void f();
      };
  };
template<typename T> using X = typename A<T>::B;
template<typename T> void X<T>::f() { } // ceci définit-il A<T>::B::f()? Ça dépend de T!

Jens Maurer trouve qu'on pousse fort l'obfuscation ici. C'est faisable, à première vue, mais ça peut devenir complexe si on considère des cas moins banals. Jonathan Caves suggère de restreindre les usages aux cas simples (raccourci pour un type de retour de fonction, par exemple) mais n'est pas sûr comment l'exprimer.

On a une résolution connexe pour l'item 1286, dont on peut s'inspirer.

Richard Smith fait remarquer qu'il est agaçant qu'une spécialisation partielle ait ici un meilleur traitement qu'une version générique. Faudra écrire un truc, ce que Jason Merrill va faire... mettons...

On travaille sur des bogues de la bibliothèque standard.

Dans sa version actuelle, raw_storage_iterator fait des copies et ne supporte pas le mouvement, ce qui bloque certaines manipulations de types incopiables. On propose d'ajouter une surcharge de operator=(T&&) qui ferait un placement new. Stephan T. Lavavej signale qu'il y a un piège ici car placement new n'a pas l'exigence que l'objet construit soit identique à l'objet d'origine. Il ajoute que ce serait un bon moment pour ajouter une fonctionnalité qui fait un relais parfait d'un U&&, mais constate ensuite que ça casserait le code existant. Je demande si ça peut causer des bris silencieux, qui exigerait une sorte de move_if_noexcept, mais Stephan T. Lavavej et Howard Hinnant semblent passer que ce n'est pas un risque (ça devrait être inobservable). Stephan T. Lavavej insiste sur le fait que personne n'utilise vraiment raw_storage_iterator dans la bibliothèque standard. Ok.

La formulation de get_temporary_buffer() est confuse, en particulier dans sa version japonaise, quant à la quantité de mémoire qui sera effectivement allouée (surtout pour le minimum; la fonction peut retourner moins que ce qui lui est demandé). Hubert Tong demande comment cette fonction interagit avec les autres mécanismes d'allocation de mémoire. Plusieurs gens ne sont pas convaincus du rôle de cette fonction; je présume qu'elle n'est que peu utilisée. Ok.

La fonction addressof() devrait être constexpr. Jonathan Wakely fait remarquer que cette fonction requiert reinterpret_cast, donc faudra du Compiler Magic pour qu'elle soit constexpr. Stephan T. Lavavej est d'accord, mais c'est de la magie simple à réaliser. Jonathan Wakely suggère qu'on consulte les implémenteurs des compilateurs avant de trancher de notre côté. On va dans cette direction.

Rien ne dit que unique_ptr<T>::get_deleter()(p) doive être capable de détruire *p, mais rien ne dit non plus que le unique_ptr<T> n'utilisera pas *p par la suite. Un libellé est proposé qui propose un discours sur la mort du deleter. On jase de choix terminologiques. Ça ne semble pas un dossier assez « mature » pour être traité ce soir.

Faudrait ajouter des spécialisation de std::hash pour les types entiers étendus, par exemple les entiers sur 128 bits. On s'entend pour Ok.

Il manque une contrainte SFINAE de haut niveau. Ça revient à plusieurs à plusieurs endroits dans le standard, c'est répétitif, mais faudrait mieux faire. On pourrait alors parler de « [telle ou telle expression est] valid in contrived argument deduction context for types [T, U, ...] ». La difficulté est de bien définir « valid in contrived argument deduction context for... ». On met du monde là-dessus.

Les types std::pair et std::tuple ne sont pas correctement écrits pour std::is_constructible dans le cas sans paramètres. Howard Hinnant explique par un exemple :

struct X
{
   X() = delete;
};
int main()
{
   using P = std::pair<int, X>;
   static_assert(!std::is_constructible<P>::value, "");
   static_assert(!std::is_default_constructible<P>::value, "");
   using T = std::tuple<int, X>;
   static_assert(!std::is_constructible<T>::value, "");
   static_assert(!std::is_default_constructible<T>::value, "");
}
// For me these static_asserts fail. And worse than that, even asking the
// question fails (as opposed to gets the wrong answer):
asseassert(!std::is_constructible<P>::value);

La proposition est un tour de passe-passe avec enable_if. On en profite pour demander de zapper quelques conseils sur l'implémentation, mais ça alourdit le processus alors on laisse faire. Jonathan Wakely dit souhaiter très fort un nouveau feature discuté dans une rencontre antérieure qui générerait les constructeurs au besoin s'ils ne sont pas explicitement supprimés pour des agrégats « simples » pour std::pair ou std::tuple.

Il semble que les traits is_trivially_constructible et is_trivially_assignable soient toujours faux. C'est un problème de terminologie, la prescription dans le standard étant incorrecte. On en profite pour faire une retouche pour clarifier le fait que declval<T>() ne soit pas odr-used. Ok.

Certaines transformations peuvent mener à des types impossibles. Alisdair Meredith dit qu'on a probablement déjà réglé ceci par une reformulation de CWG sur les types referencible. Marshall Clow pense que non. Ville Voutilainen dit l'avoir vu ailleurs. La résolution semble Ok. Go.

Semble qu'on n'aura pas nécessairement les coroutines ce matin. Jens Maurer et Gor Nishanov ont travaillé jusqu'à minuit hier sur la proposition et on a quelques trucs liés aux mots clés (yield? coreturn? co_return? Ce genre de truc) à valider. Faut voir ce qui est harmonieux, mais aussi ce qui cassera le moins de code existant (le mot yield, en particulier, en est un qu'on suspecte populaire dans la pratique alors on risque de nuire aux gens si on le réserve).

Item : James Widman a une nouvelle formulation pour les initialisations avec accolades. Il y a des subtilités grammaticales sur le rôle des virgules, en particulier dans le cas des répétitives for sur des intervalles, mais Jonathan Caves explique que c'est pour éviter des ambiguïtés dans certaines manipulations naïves de gens qui passeraient à ce modèle à partir de répétitives for traditionnelles. C'est bien fait, Ok.

N4429 : au lieu de synthétiser des constructeurs chez l'enfant, on cherche maintenant à rendre les constructeurs du parent accessibles au name lookup. Ça enlève plein de bizarreries. Un changement subtil est que using dans une classe introduit maintenant un ensemble de déclarations plutôt qu'un nom, car un constructeur, au sens de C++, n'a pas de nom.

Jonathan Caves fait remarquer que c'est beaucoup mieux qu'avant, mais qu'il semble toujours y avoir une dichotomie entre les constructeurs et les autres membres. Richard Smith souligne qu'il n'est pas arrivé à les amener plus près l'un de l'autre, les méthodes de lookup étant différentes. Ce sera plus rapide aussi, car ça enlèvera des étapes intermédiaires de construction (et des risques de copies).

On a des retouches à faire sur les règles d'accès des constructeurs du parent dans la classe dérivée. La gestion des fonctions « spéciales » (copie, mouvement, destructeur) entre enfant et parent demande beaucoup, beaucoup d'attention. On y met pas mal de temps, c'est bien mais il reste des retouches à faire et c'est plein de pièges. Faut l'équilibre entre « dire quoi faire, pas comment » et « spécifier l'ordre dans lequel les opérations surviennent » pour qu'il soit possible d'écrire du code sémantiquement portable (p. ex. : l'ordre dans lequel les paramètres avec valeurs par défaut sont construits dans ce cas-ci).

On jase technique pour la gestion de la pile et la réduction des copies. C'est amusant d'être dans la salle avec les principaux auteurs de compilateurs et discuter technique dans ces cas extrêmes. Le changement proposé a un effet visible au sens où :

struct Trace
{
   int n = 0;
   Trace() = default;
   Trace(const Trace &other) : n { other.n + 1 } {}
};
struct A
{
   A(Trace tr = {}) { cout << tr.n << endl; }
};
struct B { using A::A; };
struct C { using B::B; };
C c; // avant, aurait affiché 2; maintenant, affichera 1

On ne discutera pas l'article de Jens Maurer tout de suite sur l'intégration de noexcept au système de types car il doit s'absenter. On va plutôt traiter des problèmes à la pièce.

Le cas suivant est mal formé parce que la liste d'initialisation d'une référence ne tient pas compte des fonctions de conversion :

struct D{};	struct S { operator struct D &(); } s;
// D &d{ s }; // incorrect, mais discutable
D &dd = s; // Ok
D ddd = dd ; // ok

AvAvec une ref-vers-const, on créerait une temporaire et ça passerait, mais la création d'une temporaire est un cas discutable (pourquoi, après tout?). C'est probablement un oubli dans le cas des listes d'initialisation. Jason Merrill suggère d'utiliser des règles de 8.5.3 ici. Richard Smith dit oui, mais en escamotant le cas de la génération de temporaires. Ok.

On escamote certaines qualifications lors de certaines conversions :

template<typename T> T make();struct B {}; struct D : B {};
const int *p1 = make<int*>();           // ok, qualification conversion
const int *const *p2 = make<int**>();   // ok, qualification conversion
const int **p3 = make<int**>();         // error, not type safe

const int &r1 = make<int&>();           // ok, binds directly
const int *const &r2 = make<int*&>();   // weird, binds to a temporary
const int *&r3 = make<int*&>();         // error
const int &&x1 = make<int&&>();         // ok, binds directly
const int *const &&x2 = make<int*&&>(); // weird, binds to a temporary
coconst int *&&x3 = make<int*&&>();       // weird, binds to a temporary

C'est pas nécessairement gentil. La question est de déterminer ce qui serait un comportement raisonnable. Pas clair.

Cas étrange : le ternaire ne réalise pas les mêmes séquences de conversion pour les pointeurs et pour les références. On passe pour le moment.

Cas de types dépendants et Parameter Packs. Par exemple :

template<typename ...Ts> struct X { X(int); };
template<typename T> using Y = int;
template<typename ...Ts> void f() {
   X<Y<Ts>...> x;
}

L'ellipse devrait mener à un type dépendant, mais c'est pas écrit. L'erreur est que X<int...> n'a pas de constructeur par défaut. C'est relativement simple à régler (un petit ajout de texte pour tenir compte du cas du Pack Expansion)

Questionnement à savoir si le code ci-dessous devrait être valide. Probablement pas, mais les implémentations divergent :

template<typename ...T>
   struct X
   {
      void f();
      static int n;
   };
template<typename T, typename U>
   using A = T;
template<typename ...T>
   void X<A<T, decltype(sizeof(T))>...>::f() {}
template<typename ...T>
   void X<A<T, decltype(sizeof(T))>...>::n = 0;
void g()
{
   X<void>().f();
   X<void>::n = 1;
}

Semble que ce soit un duplicat d'un cas déjà traité.

On a un échange ensuite sur une résolution avec laquelle Hubert Tong est en désaccord, sur le plan de la terminologie de valeur en termes de classes et de leurs attributs. On discute de la nuance entre valeur et (rvalue, glvalue, xvalue, etc.), le premier ne s'appliquant qu'aux scalaires et le second étant applicables aux entités de class type qui sont en fait des expressions.

Hubert Tong est d'avis que la valeur d'une classe peut être modifiée par la modification de la valeur d'un de ses attributs, alors que Richard Smith est d'avis que cette terminologie devrait (outre pour les union) se limiter aux scalaires.

La question des bitfields est soulevée : ont-ils un corresponding object?

Hubert Tong fait référence à 3.1 pour indiquer que les objets trivialement copiables ont une valeur. Il met en relief un tableau d'éléments contenant en premier attribut un int, dans quel cas accéder à un élément du tableau par un int* permettrait de modifier un int. On cherche une terminologie simplifiant 3.10 mais permettant clairement d'exprimer que modifier directement un sous-objet modifie aussi l'objet le contenant.

Hubert Tong suggère qu'on laisse le WG14 (langage C) y jeter un coup d'œil avant que l'on n'y touche, puisque cela pourrait affecter la compatibilité entre les langages, mais Richard Smith pense que C, plus laxe ici, pourrait raisonnablement choisir de traiter le dossier autrement. On ajoutera un passage de clarification à ce qui est proposé.

On se demande ensuite se ceci mène à un comportement indéfini :

int f()
{
   union U { double d; } u1, u2;
   (int&)u1.d = 1;
   u2 = u1;
   return (int&)u2.d;
}

Hubert Tong pense que l'affectation à la deuxième ligne devrait être illégale. Richard Smith dit qu'une passe comme ça est un cas de memcpy(). Jason Merrill trouve ça insatisfaisant dû à une copie redondante. Richard Smith dit que « memcpy() est spécial »; faut pas regarder trop creux sous la couverture.

On se demande si reinterpret_cast ne devrait pas être défini en ces termes. On est très près d'un truc comme aligned_storage ici… Adopter le document sur std::launder() fermera ceci.

Jens Maurer revient alors on aborde son texte proposant d'intégrer les spécifications d'exceptions au système de types. On pense entre autres aux pointeurs de fonctions ici, soit codifier le comportement attendu lors d'une copie d'un pointeur de fonction noexcept(false) dans un pointeur de fonction noexcept(true) par exemple.

 Se préoccupe-t-on de noexcept seulement ou traite-t-on aussi des clauses throw()? Les clauses throw() sont transformées en une forme noexcept appropriée pour les besoins des conversions. La formulation générale suit celle utilisée pour les fonctions transaction_safe et celles qui ne le sont pas.

Les travaux reprennent vers 13 h 30. Un gros après-midi s'annonce, où on doit examiner plusieurs dossiers soumis à notre attention pour les classer en ordre de priorité.

On poursuit les travaux entrepris avant le dîner sur l'intégration des spécifications d'exceptions au système de types. On vérifie l'interaction de noexcept et du polymorphisme dynamique (on ne peut pas devenir plus laxe en spécialisant). On vérifie aussi l'interaction des spécialisations de templates et de noexcept (oui, ça se fait). On ne peut par contre pas faire de surcharge sur la seule base de la présence ou non de noexcept.

On passe ensuite au classement des dossiers par priorité. On indique au passage qu'il est probable qu'une téléconférence survienne entre maintenant et Kona, impliquant CWG et EWG, pour régler des « issues » du EWG qui est débordé.

Item : permettra-t-on d'appliquer reinterpret_cast entre deux types de même taille et de même alignement? On l'envoie à EWG (on cherche ensuite l'endroit où on indique que lire d'un int non-initialisé est un comportement indéfini, et on ne le trouve pas...)

Item : Template default arguments and deduction failure. C'était passé de CWG à EWG et ça revient à CWG. On parle de cas comme ceci :

template<typename T> struct Wrapper;
template<typename T = int> void f(Wrapper<T>*);
void g()
{
   f(0);
}

Ceci ne déduit pas T alors on présume int, mais c'est pas universel alors faut préciser le texte. On a un autre item, qui est en bonne partie connexe :

template <class T = int> void foo(T*);
void test()
{
   foo(0); // #1 valide?
   foo<>(0); // #2 valide?
}

Ici, test() est rejeté par la plupart des compilateurs. On va essayer de résoudre les deux. Jason Merrill indique qu'il faut continuer d'essayer de faire la déduction même si ça échoue. John Spicer est d'avis qu'on devrait avoir un statu quo, et que les deux foo de test() sont invalides, le paramètre m'ayant pas assez d'information pour permettre une déduction. Jason Merrill s'oppose à ce que ce code compile.

Item qui revient aussi d'EWG : on nous demande d'accepter des const float en tant qu'expressions constantes, mais on est conscients que ça pourrait briser les ABI. Ça fait peur parce que ça brise le code (et il existe une alternative : constexpr float!). On penche pour NAD, parce qu'on ne se voit pas faire chuter des avions du ciel ou des trucs semblables en brisant du code existant.

Item : élargir le concept de paramètres par défaut des templates aux variable templates. Ok, suffit d'ajouter deux mots à un texte existant.

Item : clarification des paramètres dans une spécialisation de templates (il y a une redondance). Ok.

Item : on nous demande de déprécier uncaught_exception() depuis qu'on a uncaught_exceptions(). Jens Maurer remarque que c'est déjà fait, donc NAD.

Item : il  ya un problème de numéros de référence dans un exemple. Éditorial.

Item : on a un bout de grammaire qui est pas mal long pour parameters-and-qualifiers. Les correctifs faits par Jens Maurer tantôt aident. NAD.

Item : une question d'équivalence ou d'équivalence fonctionnelle, à savoir si on a un f() ou deux f() avec :

template<int N> struct A {};
template<short N> using B = A<N>;
template<int N> void f(B<N>) {} // #1
template<int N> void f(A<N>) {} // #2

On place ça dans priorité 1 mais ça recoupe les discussions d'hier.

Item : ajouter une note d'incompatibilité entre C++ 11 et C++ 14 pour :

int a = 1;
auto b{a}; // int maintenant, initializer_list<int> avant

Item : les cas de conversion à bool pour noexcept et static_assert sont trop laxes présentement (on pourrait considérer 0.5 comme un booléen, par exemple).

Item : le sens de ceci a changé avec les changements de grammaire :

  auto f()->int(*)[4]; // function returning a pointer to array[4] of int
                       // not function returning array[4] of pointer to int

Item : cas de spécialisation de template et de namespace. Il y a un problème dans le texte quand on parle de spécialisation explicite de class template. Jens Maurer s'en occupe.

Item : clarification des spécifications d'exceptions pour les fonctions de déallocation (le standard est légèrement contradictoire). Est-on dans le comportement indéfini ou défini (p. ex. : appeler unexpected() ou terminate())? On hésite entre divers niveaux de priorité ou NAD puisque c'est un peu indéfini et un peu défini.... C'est un vrai problème, ce truc. Il se peut que je m'en mêle, question de me faire la main.

Item : questionnement sur l'interaction entre paramètres de templates, tableaux et décrépitude de pointeurs. Jason Merrill suggère de transformer l'écriture et, plutôt que de dire ce que n'est pas le paramètre, indiquer ce que c'est. Faudra voir.

Item : ce qui suit échoue si T est void :

T f();
decltype(auto) g() { return f(); }

Évidemment, faut arranger ça. C'est une mini retouche terminologique.

Item : la terminologie parle de paramètres « identiques » pour des templates mais on ne considère pas leurs noms. Faudrait reformuler. On va demander à Jens Maurer d'en tenir compte dans un truc que Jens Maurer fait déjà.

Item : le thread id n'est pas clair dans certains cas :

auto id1 = std::this_thread::get_id();
thread_local auto id2 = std::this_thread::get_id();
int main()
{
   auto id3 = std::this_thread::get_id();
   auto id4 = std::this_thread::get_id();
   std::cout << id1 << std::endl << id2 << std::endl << id3
             << std::endl << id4 << std::endl;
}

On l'envoie à SG1, qui s'occupe de concurrence.

Item : clarifier la terminologie de « peut lever n'importe quoi » dans le cas de fonctions.

Item : on a une contradiction dans le sens qu'on donne à static_cast, const_cast et les transtypages de C. On en fait une priorité 2.

Item : avec l'écriture actuelle, ceci est illégal :

template <int* x = {}> struct X {};

Ça semble incohérent. Jason Merrill suggère qu'on considère {} comme une converted constant expression dans ce cas. NAD, devrait fonctionner. Par contre, Jason Merrill est disposé à retoucher la définition de converted constant expression pour que le texte soit plus près de l'intention.

Item : cas de déplacement d'un paragraphe d'une section à l'autre dans le standard, par souci de cohérence. NAD.

Item : il y a divergence sur la validité de ceci, à savoir s'il s'agit d'un contexte SFINAE ou non :

struct A { operator int(); };
template<typename T> T operator<<(T, int);
void f(A a) { 1 << a; } // operator<<(int,int)? Substitution Failure?

On va y aller avec la résolution proposée.

Item : il manque une retouche dans la définition des λ génériques pour exclure le cas où on a un truc comme :

auto f = [] () ->T // c'est le type de retour explicite qui la rend non-générique
{
}

Item : on nous rapporte que ceci devrait être bien formé, mais n'est pas permis par le standard :

template <class T, class U> struct X
{
   typedef char member;
};
template<class T> struct X<T, typename enable_if<(sizeof(T)>sizeof(float)), float>::type>
{
   typedef long long member;
};
int main()
{
    cout << sizeof(X<double, float>::member);
}

On y va pour une priorité 2.

Item : avec le texte du standard, il n'est pas clair si ceci est légal ou non :

template<typename... T> void f(typename T::type...) { }
int main()
{
   f<>();
}

Idem pour ceci, qui est plus complexe :

template<typename ...T> struct tuple {};
template<typename ...T, int, typename ...V>
   tuple<T...> f(V...);
int main()
{
   f<>();
}

La bonne nouvelle, c'est que tout le monde en déduit une séquence vide à l'appel, mais c'est difficile de voir ça dans le texte du standard. Un autre cas semblable est :

template <int> struct A;
template <int ...N, typename T> void foo(A<N> *..., T);
void bar()
{
   foo<0>(0, 0); // Ok: N est un paramètre du template, T est int.
   foo<0, int>(0, 0); // error: int does not match the form of the corresponding parameter N.
}

Richard Smith fait remarquer qu'on permet les parameter packs ailleurs qu'à la fin dans les fonctions, parce qu'on peut parfois s'en tirer avec les paramètres, mais pas pour les types. On a un priorité 1 ici, et faudra y revenir demain.

Item : on a un comportement indéfini avec ce qui suit, mais c'est discutable :

class B
{
public:
   int f();
};
class C
{
public:
   C(int);
};
class D
   : public B, C
{
public:
   D() : C(f())  // undefined: calls member function
                 // but base C not yet initialized
   {
   }
};

Je comprends l'intérêt, mais écrire la règle... Hubert Tong rappelle qu'il ne faut pas permettre ça avec une méthode virtuelle. Ici, la subtilité normative est que lors de l'appel de f(), on n'est pas (encore!) en train de construire D; la situation est qu'on a fini de construire B et on s'apprête à construire C. Il se peut que je m'en mêle.

On a la visite de Robert Douglas pour N4417 v3. Faut examiner la formulation de son texte.

On vérifie les cas d'initialisation, la présente de feature test macros, ce genre de truc.

On a le terme presumed à divers endroits, ce qui a trait aux usages du préprocesseur pour __FILE__ et autres, mais Jens Maurer fait remarquer que ça ne s'applique pas à __func__ qui revient au compilateur.

Le type des fonctions qui retournent le numéro de lignes est discuté : le document indique size_t mais vu que __LINE__ est une macro, c'est pas clair que ce soit à propos. Hubert Tong vérifie le standard C, qui indique un requis minimal de 16 bits pour size_t alors que __LINE__ pourrait être 32 bits, alors faut au moins 32 bits.

Il y a aussi des retouches à faire dans la présentation (commentaires qui changent de ligne). Faut aussi traiter le cas de l'initialisation par agregate initializer (qui peut escamoter le constructeur).

Richard Smith indique qu'il souhaiterait avoir une latitude quant aux paramètres à la construction parce qu'un diagnostic est requis et que ça lui facilitera la vie. Il y a des should (ce qui signifie « implementation defined, but you are encouraged to get it right », dixit Richard Smith).

On discute de la nuance entre implementation-defined et unspecified pour les noms de fonctions rapportés par l'outil proposé : sont-ils décorés ou non, par exemple?. Pour le nom de la fonction, que fait-on dans une λ? Jonathan Caves pense qu'on a statué pour operator() dans ce cas. Roger Orr fait remarquer qu'un nom de fonction vide serait acceptable puisqu'on en a fait un cas de qualité d'implémentation. Hubert Tong fait remarquer que l'encodage de caractères est non-spécifié (on blague : Richard Smith suggère une saisie d'écran encodée comme une séquence de bytes, mais sans valeurs nulles; Jason Merrill suggère un uuencode.

Hubert Tong parle de la difficulté de déboguer pour trouver le paramètre qui nous fait souffrir dans un Parameter Pack. John Spicer fait remarquer que le concept de numéro de colonne est difficile à définir. Un participant souligne que si on considère unicode, ça peut devenir vilain. Hubert Tong fait remarquer qu'il est possible que la ligne rapportée par __LINE__ au moment où le préprocesseur intervient diffère de ce que le compilateur voudrait rapporter, alors on a encore ici un cas d'implementation-defined.

Robert Douglas lance en boutade qu'il se sentira personnellement insulté si les gens utilisent le fruit de son travail dans des macros, considérant ce qu'il fait justement pour se débarrasser de macros.

Item : les template templates avec paramètres par défaut. On n'est pas certains comment traiter ceci, qui semble raisonnable :

template<typename T1, typename T2 = char>
   class A { };
template<template<typename... T> class X>
   class S
   {
      X<int> x;
    };
S<A> a;

Item : petite retouche à faire dans la formulation de l'édition des liens et des espaces nommés.

Item : on revient sur ceci, qu'on a déjà vu :

auto f() {
   static int n = 123;
   struct X { int &f() { return n; } };
   return X();
}
int &r = decltype(f())().f();

L'idée est qu'il est maintenant possible de définir des fonctions dont le type de retour n'a pas de spécifications de liens. Il y a aussi des ennuis avec les fonctions extern "C".

Item : le standard n'indique pas si une spécialisation explicite d'une fonction template peut avoir un type de retour déduit. Est-ce grave? Jason Merrill dit que non, alors NAD.

Item : avec les espaces nommés inline, ceci semble brisé :

namespace A {
   inline namespace b {
     namespace C { struct X { }; }
   }
}	
namespace A { C::X x; }

C'est la définition de declarative region qui semble incorrecte ici. Jason Merrill est d'avis qu'un using namespace b; est implicite dans A. On note que l'exemple original lors de la soumission du bogue était plus complexe et plus réaliste :

namespace A {
   inline namespace b {
      namespace C {
         struct X { };
      }
   }
}
namespace A {
   namespace C { // <-- ah! C'est pas fin, ça
      struct Y : X { };
   }
}

John Spicer pense que ça ne devrait pas marcher : les espaces nommés inline devraient être transparents aux usagers, pas au concepteur. Cela dit, c'est pas unanime. Jens Maurer va essayer d'écrire quelque chose qui rendrait l'exemple légal.

Item : Hubert Tong fait remarquer que rien ne semble rendre ce qui suit illégal dans le texte du standard :

  template <typename> struct A;
  template <unsigned> struct A;

Ça rejoint le bogue de « listes de paramètres identiques » rencontré plus tôt. On va devoir définir le tout mais ça ressemble à la terminologie pour les signatures de fonctions

Item : le langage C supporte ça, mais voulons-nous vraiment le faire aussi?

struct A {
   struct B { int x; } b;
   int B;    // Permitted in C
};

Hubert Tong suggère que oui, pour éviter d'introduire un cas d'exception. Jonathan Caves demande (en riant) s'il peut dire over my dead body. On signale que si int B est static, on a un A::B ambigu. Semble que les compilateurs l'acceptent... On est triste. Jonathan Caves dit que ça ne devrait pas fonctionner si B est un template.

Item : on a deux phrases à propos de decltype(expr) qui ne sont pas d'accord l'une avec l'autre. On a un jeu sur équivalence ou équivalence fonctionnelle :

template<typename, typename = decltype(sizeof(0))> struct X;
template<typename T> struct X<T, decltype(sizeof(T()))> {
   typedef int type;
   void f() {
      X<T, decltype(sizeof(T()))>::type m; // ok, current instantiation
      X<T, decltype(sizeof(int))>::type n; // error, not the current instantiation, need decltype
   }
};

Jens Maurer va essayer de trouver une formulation.

Item : la définition de current instantiation of a partial specialization est incorrecte. Retouches terminologiques à faire.

Item : est-ce que type-dependent implique value-dependent?

template<int>   struct X
   {
      typedef int type;
   };
template<typename T>
   struct Y
   {
      void f()
         { X<false ? this - this : 0>::type x; } // missing typename?
   };
void g()
   { Y<void>().f(); }

Est-ce ce qu'on veut? On n'est pas sûrs... Jason Merrill et d'avis que le statu quo est souhaitable ici. Jens Maurer va l'écrire pour expliciter le propos.

Item : on a un passage sur les variadiques qui dit qu'exiger un Parameter Pack vide est incorrect, mais il semble que le permettre aux compilateurs pourrait être Ok. À suivre, faut y réfléchir.

La liste à examiner est disponible sur http://cplusplus.github.io/LWG/unresolved-prioritized.html

Item : clarifier les exceptions sur les flux. On va y penser...

Item : extraire des données d'un flux... avec Perfect Forwarding... et des char*... Ouch! Ce qu'on regarde, c'est un peu le gets() de C++! Review status

Item : semble être un truc terminologique. On n'y touche pas.

Thomas Köppe se joint à nous et offre le scotch. Merci!

Item : on impose aux facettes qui ont un service _byname de respecter un contrat sémantique sinon on a un comportement indéfini. Ok. Review status est envisagé, mais Jonathan Wakely a un malaise parce qu'il utilise des classes dérivées d'un parent facette en pratique (méchant Jonathan!). Open alors.

Item : l'écriture ne rejoint pas les attentes usuelles pour les postconditions et la gestion des exceptions (Marshall Clow souhaite un article sur le LWG issue 2136, qui est le problème général)

Item : il manquerait des constructeurs à regex<...>::match_results, que je ne connais pas. La bonne nouvelle : si on le fait, on ne brisera rien puisque personne ne les appelle présentement, par définition. Jonathan Wakely fait remarquer que les match_results ne peuvent être construits que par un regex, mais que les versions munies d'allocateurs sont pertinentes. Les opérations impliquant des allocateurs peuvent avoir des noexcept conditionnels puisque les allocateurs peuvent être Stateful maintenant. Il y aura des retouches terminologiques à faire.

Item : allocateurs si T est volatile : non Ok.

Item : définir program-defined, et remplacer user-defined par program-defined. La subtilité : il y a beaucoup de trucs user-defined, et selon le standard la bibliothèque standard est user-defined... Hubert Tong met les freins. Richard Smith demande comment on qualifierait un truc comme std::swap<X>(X&,X&) pour un type X maison devrait être qualifié. Thomas Köppe demande comment qualifier vector<int>. Ouf, je pense que c'est pas un truc qu'on va clore ce soir . Jonathan Wakely clarifie sa pensée pour les types comme vector<int>.

J'aimerais clore l'item 2372, mais c'est mal reçu... On parle de l'initialisation d'une std::string avec un entier. C'est le cas 0, pointeur nul, qui est un problème (les autres, je m'en fous un peu).

On commence par le document retouché par Robert Douglas sur le Source-Code Information Capture, où il a tenu compte des recommandations faites par CWG hier.

Il reste des trucs mineurs à retoucher, comme le choix de police de caractères à certains endroits, mais c'est à peu près ça. La terminologie de la méthode current() est particulière parce qu'elle laisse de la latitude aux implémentations quant à ce que signifie « la ligne courante » dans le code source.

Les choix des mots sont très importants à CWG : le terme implementation-defined fields, par exemple, fait réagir car le mot fields n'est pas normé (on préfère implementation-defined value à implementation-defined fields).

Hubert Tong se demande quel sens on devrait donner au constructeur par défaut, ce détail n'étant pas clair à ses yeux. Il n'a pas tort : le document ne le dit pas!

Nous avions souligné hier le problème du choix d'un type pour représenter le numéro de la ligne courante dans le code source, le choix initial dse Robert Douglas ayant été size_t, ce qui semble raisonnable à ceci près que ce type entier non-signé pourrait, dans des cas dénégérés, être encodé sur 16 bits. Robert Douglas a mis unsigned long long comme type pour les numéros de lignes parce que le standard impose un minimum de 32 bits pour ce type, mais on se demande pourquoi on n'a pas demander uint_least32_t. Jens Maurer fait remarquer que le type unsigned long long pourrait être 64 bits et donc, sur une machine 32 bits, pourrait utiliser deux registres. Richard Smith fait remarquer que les valeurs calculées doivent l'être efficacement, mais les types utilisés à l'interne n'ont pas à être les mêmes que ceux exposés par l'accesseur.

Dinka Ranns demande si le document retournera à LEWG ensuite; oui, on ne fait que retravailler la formulation.

On revient sur D4518, qui propose d'intégrer les spécifications d'exceptions au système de types.

Il reste une coquille dans un des exemples sur les pointeurs de fonctions. Hubert Tong demande si les pointeurs avec et sans noexcept sont compatibles pour ce qui est des va_arg calls. Richard Smith pense que oui. Jens Maurer ajoute une note pour en tenir compte (ici, faut distinguer va_arg, qui touche surtout à la compatibilité avec C, langage qui ne supporte pas les exceptions, des templates variadiques, qui touchent à C++ et sont conscients des exceptions)). Jason Merrill est inconfortable avec le changement et préférerait le statu quo; on revient sur nos pas.

Dinka Ranns s'interroge sur le nombre de conversions à faire lors de conversions de fonction f(T) noexcept à fonction f(T). On clarifie et on allège un peu, à quelques endroits. Une partie du travail est de « normer » le texte de manière à ce que les compilateurs soient en mesure de bien résoudre les ambiguïtés entre signatures distinctes de fonctions, même si nous ajoutons les spécifications d'exceptions dans la liste de critères et même si on ne peut surcharger les fonctions sur cette base.

RS demande si affecter une λ sans capture qui ne lève rien, comme la λ minimale []{}, à un pointeur de fonction noexcept comme void(*p)() noexcept, demeure légal. Avec les changements, ce code devient illégal alors qu'il passait avec C++ 14 :

void g1() noexcept;void g2();
template<class T> int f(T *, T *);
int x = f(g1, g2);

Quand on examine les surcharges possibles, avec ou sans noexcept, on a le cas des using à examiner, qui peuvent introduire des noms dans le lookup contextuel et provoquer des ambiguïtés, ce qui est correct ici mais doit être permis par l'écriture du standard.

#include <iostream>
using namespace std;
void g()
   { throw []() { cout << "Wow!" <<  endl; }; }
int main()
{
    try
       { g(); }
    catch (auto &f)
       { f(); }
}

#include <iostream>
#include <functional>
using namespace std;
void g()
   { throw []() { cout << "Wow!" << endl; }; }
int main()
{
    try
       { g(); }
    catch (function<void()> f)
       { f(); }
}

#include <iostream>
using namespace std;
void g()
{
   throw (void(*)())([]() { cout << "Wow!" << endl; });
}
int main()
{
   try
      { g(); }
   catch (void (*f)())
      { f(); }
}

Richard Smith suggère une petite retouche au document intégrant les spécifications d'exceptions au système de types. On le soumettra au vote cet après-midi. On ne pensait pas mettre de macro pour fins de Feature-Test parce qu'on ne voit pas de moyen raisonnable d'écrire du code qui compile conditionnellement sur la base de cette facilité ou de son absence, mais on en ajoute une par acquis de conscience.

Pour le document sur la mémoire transactionnelle, on doit valider la conformité des changements que Michael Wong a faits. On fait le tour et ça semble beau. Richard Smith dit qu'il a des doutes sur les teintes de vert pour les sections contenant des changements, mais on va faire avec . Ok. On change le « D » pour un « N » sur le document pour qu'il passe de « en développement » à « normatif ».

On a encore 57 minutes alors on va examiner la proposition de Gor Nishanov (qui vient nous rejoindre) sur les coroutines. Celle-ci ne passera pas cette semaine, mais on a des chances pour Kona.

Hubert Tong demande si on doit prévenir des coroutines qui seraient extern "C". Gor Nishanov signale que les coroutines sont en fait des fonctions donc que c'est pas grave.

Jason Merrill demande où retourne un cowait appelé dans un constructeur ou dans un destructeur; évidemment, les fonctions spéciales ne peuvent être des coroutines mais elles peuvent les appeler. Gor Nishanov explique le modèle mental à adopter avec sa proposition pour raisonner sur le code.

Quel est l'impact d'utiliser une coroutine pour initialiser une variables statique? Faut utiliser coawait, comme on le ferait ailleurs.

Hubert Tong demande ce qui se passe si on longjmp dans une coroutine suspendue; Gor Nishanov dit que c'est pas fin. Il faut mettre des mots à ce sujet.

Dans les exemples, on a des suspend resume point 0 et on se demande quel sens donner au « 0 »; Gor Nishanov dit qu'il cherche une notation pour indiquer que c'est là que se trouve le code spécial à générer. Le rôle de cette chose est de signaler un point de retour, une sorte d'étiquette. En pratique, ce serait une surcharge d'operator,() mais ça se lisait drôle. Richard Smith suggère une pseudo expression.

Les mots comme cofor sont un peu bof... On cherche une alternative. Gor Nishanov dit qu'il aimerait bien cor. Je suggère gor, à titre éponyme. On rigole un peu.

On demande ce qu'on obtiendrait avec :

future<int> f();
// ...
decltype(coawait f);

Gor Nishanov dit que ça échouerait probablement. Bien sûr, decltype(coawait f()) serait int.

Quelqu'un demande si on pourrait ajouter un coto, à l'image du goto. On rigole.

Hubert Tong demande pourquoi on ne peut passer que des types déplaçables à des coroutines. Gor Nishanov explique qu'en général, on n'a pas de pile alors il nous faut ce mécanisme. Hubert Tong demande pourquoi on n'accepte pas la copie. Gor Nishanov pensait l'avoir permis. On retouche.

John Spicer demande un exemple dans la section 8.4.4. Hubert Tong ajoute que pour des points bonis, faudrait que ce soit une λ.

Les règles pour la plénière semblent être que les chair des SG et des WG doivent s'assurer que les propositions à débattre soient écrites, nettoyées et prêtes à être présentées pour 13 h 30. Des Progress Reports seront présentés sur chacun des dossiers chauds/ chaque famille de dossiers chauds (il y en a 15, à l'oeil). Certains des SG sont fermés, ayant terminé leur travail, et le fruit de leur boulot étant traité dans des WG.

Le SG2 sur les modules est inactif.

Le SG3 sur les systèmes de fichiers est inactif.

Le SG5 sur la mémoire transactionnelle : Michael Wong dit qu'on a atteint notre objectif. Le TS est prêt à être voté. CWG proposera d'adopter le TS. On continuera par la suite à examiner ce qui pourrait être développé de ce côté pour Kona, et on l'implémentera au moins dans gcc et dans clang.

Le SG6 sur les numériques : Lawrence Crowl dit qu'on a un début de TS qui se tient pas mal. Ça avance bien. On ne sera pas prêt pour un TS à Kona, mais probablement au WG21 suivant.

Le SG7 sur la réflexivité : Chandler Carruth dit qu'on a eu plusieurs propositions, et on a de grosses décisions de design à prendre. Quelques trucs se promènent dans LEWG. On aura d'autres propositions pour Kona. Je ne sais pas quand on va livrer un TS car les décisions sont lourdes. On n'a pas de nouvelles pour les Type Property Queries car l'auteur n'était pas présent.

Le SG8 sur les concepts est inactif

Le SG9 sur les intervalles : Marshall Clow dit qu'ils ne se sont pas rencontrés. Il y avait une proposition, mais c'était le gros document d'Eric Niebler, qui est allé à LEWG en tant que proposition. Les explorations électroniques se poursuivent, mais on va au moins continuer de faire progresser les travaux autour de la proposition d'Eric Niebler. Ça va se passer en bonne partie à LEWG.

Le SG10 sur le Feature Testing : Clark Nelson dit que le groupe s'est rencontré et a réussi à intégrer des Feature Test Macros dans quelques TS. Ce que a été fait pour C++ 14 était tardif et un peu faible, mais ils pensent faire un meilleur boulot pour C++ 17. On a un texte Boilerplate pour les TS d désormais. Gabriel Dos Reis ajoute qu'à son avis, le texte de Feature Test devrait être obligatoire dans chaque TS. Clark Nelson dit qu'une explication des raisons pour lesquelles ce pourrait ne pas être nécessaire sera aussi acceptable. John Miller parle de nuances entre les requis pour les TS et ceux pour les IS.

Le SG12 sur le comportement indéfini : Gabriel Dos Reis indique que le groupe ne s'est pas rencontré car ses participants-clés étaient dans CWG et LEWG.

Le SG13 sur les entrées/ sorties : Herb Sutter dit que le groupe de s'est pas rencontré. L'affichage 2D n'est complété qu'à 80%, mais c'est très gros (heureusement, l'auteur est un ex-avocat). On compte l'examiner d'ici Kona et le présenter alors.

Le SG1 sur la concurrence : Hans Boehm dit que deux TS ont été traités par eux cette semaine :

• Le Parallelism TS1 (algorithmes, gestion des exceptions)
• Le Concurrency TS1 (amélioration des futures, latches, barriers, pointeurs intelligents atomiques, entre autres)

Dans le collimateur :

• Le Parallelism TS2 (cumulatives, exécuteurs, task regions, simd)
• Le Concurrency TS2 (exécuteurs, lock_guard variadiques)

Autres trucs divers discutés cette semaine : is_always_lock_free(), les coroutines (avec EWG), les promesses, la mémoire Thead-Local, memory_order_consume, les atomiques, le π-calcul, etc.

EWG : Ville Voutilainen dit qu'ils ont traités presque toutes les propositions apportées. Ont donné des orientations pour les tableaux dynamiques, la mémoire transactionnelle et les concepts. Les comparaisons par défaut et les fonctions résumables ont aussi avancé. Ils n'ont traité aucun « issue », faute de temps. Les modules avancent. Les contrats aussi. Pas de consensus pour la syntaxe uniforme des appels de fonctions. Les stackful coroutines ne sont pas un dossier clos. Ils ont une courte liste de propositions acceptées, neuf cas de ropositions rejetées.

CWG : Mike Miller parle de notre traitement des commentaires sur les concepts et la mémoire transactionnelle, du travail sur la terminologie et les formulations relayées par EWG et LEWG, et d'un grand nombre d'« issues ».

Pour les concepts :

• Le PDTS se ferme la semaine prochaine. On ne peut pas le voter cette semaine
• Quatre pays avaient soumis leurs commentaires d'avance. Merci!
• Rencontre commune entre CWG et EWG pour discuter de design
• Le constrained auto a été accepté et implémenté
• Les autres commentaires ont été rejetés pour le TS courant mais pourront être réexaminés dans un TS subséquent
• Tous les autres commentaires ont été traités
• On vise un CWG par téléconférence suite à la fin du vote, pour réviser le document en conséquence
• On devrait pouvoir statuer à Kona; Herb Sutter indique qu'on pourrait même statuer lors de la téléconférence si tout est propre

Pour la mémoire transactionnelle :

• On a traité les commentaires approuvés par CWG et LWG
• Le TS final intégrant tout ça a été publié
• On va voter aujourd'hui

Autres propositions examinées et par EWG et examinées CWG :

• Intégrer les spécifications d'exceptions au système de types (N4320), vote prévu aujourdhui
• Reformuler les constructeurs hérités (N4429), presque prêt
• Coroutines (N4499), en cours

Autres propositions examinées et par LEWG et examinées CWG :

• Source-Code Information Capture (N4417), en cours

Il nous reste aussi des « issues » à catégoriser. On passe au vote pour les trucs mis de l'avant pour CWG :

• Quatre défectuosités à résoudre : pas d'opposition
• Un paquet de défectuosités tentatively ready : pas d'opposition
• Le TS de mémoire transactionnelle : pas d'opposition
• Intégrer les spécifications noexcept au type des fonctions... C'est moins direct. À propos des échanges :
  • on ne peut surcharger sur la présence de noexcept
  • ça affecte le name mangling quand on passe un pointeur de fonction noexcept en paramètre à une fonction
  • ça affecte aussi l'instanciation des templates qui prennent un pointeur sur une fonction noexcept ou non en paramètre
  • avec un template externe instancié dans un binaire déjà livré, on pourrait avoir un bris. C'est obscur mais faudra l'arranger
  • un appel à qsort(), ça passe encore? Oui, on peut affecter l'adresse d'une fonction noexcept à un pointeur de fonction qui ne l'est pas
  • commentaire entendu : oui, ça brise l'ABI, mais c'est la chose à faire. Ajouter noexcept aux fonctions de la bibliothèque standard peut casser encore plus
  • en a-t-on discuté avec LWG? Les vendeurs peuvent ajouter noexcept à leur discrétion dans la bibliothèque standard, après tout... La réponse est non, ça n'a pas été soumis à l'attention de LWG
  • réaction : je ne pense pas que le bris va survenir. Un pointeur noexcept peut être affecté à un pointeur non-noexcept
  • réaction : je pense plus aux cas où on inspecte les types
  • réaction : pas grave, si tu spécialises pour noexcept, t'as un meilleur match, mais sinon tu as le même cas qu'avant
  • réaction : ok, c'est un peu comme const, c'est moins pire que je pensais
  • commentaire : je préférerais étudier la question
  • commentaire : j'aimerais aussi étudier l'impact sur nos binaires
  • commentaire : j'aimerais consulter des gens qui ne sont pas ici
• Clark Nelson : est-ce que LWG pourrait examiner ça demain?
• Marshall Clow : on peut essayer
• Herb Sutter : on ne perd rien en le remettant à Kona. Attendons et réfléchissons d'ici là. On sera plus efficaces en petits groupes (ça obtient l'assentiment de l'assemblée)

LEWG : Jeffrey Yasskin dit qu'ils ont couvert une trentaine de propositions. Ils ont pris le temps de les mettre en ordre, et les quatre qu'ils n'ont pas traité sont telles que les auteurs n'étaient pas ici. Il estime que son groupe a été efficace. Ils ont beaucoup parlé de variants, d'intervalles et de réseautique. Il invite les gens à le document d'Axel sur les variants pour se faire une tête. Pour les intervalles, il leur reste un détail à regarder et comptent le faire dans une téléconférence. Pour la réseautique, ils poursuivent les débats demain.

LWG : Marshall Clow dit qu'ils ont travaillé fort. Ils avaiet moins de propositions qu'à l'habitude. Ils ont vérifié deux TS, soit un sur la concurrence et un autre sur les points de personnalisation, ce dernier par Eric Niebler. Pour les points de personnalisation, ça avance bien. Il reste un peu d'expérimentation à faire.

Ils ont examiné une proposition sur des traits nothrow-swappable. Ce document proposait trois approches, et LWG a donné sa préférence. Ils ont aussi examiné une proposition sur le type des accumulateurs, mais n'y ont pas été favorables sur la base de prémisses inexactes.

Marshall Clow liste ensuite plusieurs propositions qui ont été discutées.

Quand on vient pour voter, quelqu'un s'aperçoit que les liens menant sur les propositions à voter mènent sur les textes pré-rencontre, et ne tiennent pas compte des changements apportés cette semaine. C'est une erreur technique, mais ça bloque le vote. Alisdair Meredith s'offre pour générer un document « N » pour ce soir si on veut le lire, ce qui permettrait de voter demain. Stephan T. Lavavej dit que dans bien des cas, les implémenteurs feront les changements qu'il y ait vote ou non, car les changements sont triviaux et utiles, mais se sentiront mal si on ne les appuie pas. Jens Maurer a des réserves sur des gestes précipités. John Spicer aussi.

Clark Nelson remarque qu'un groupe de liens mène effectivement sur les documents les plus récents. On pourrait stabiliser la première moitié, plus pressante et plus stable, et remettre les moins pressants (la deuxième moitié) à demain. Jeffrey Yasskin appuie la démarche d'Alisdair Meredith. Marshall Clow dit que le problème est plus complexe dans d'autres cas.

On s'entend sur une procédure. On votera demain, dans le cas des dossiers qui auront été remis à jour (probablement d'ici 17 h aujourd'hui, selon Howard Hinnant). Marshall Clow, qui est franchement très gentil et vient de vivre une heure très longue à gérer ça en public, remercie des gens.

On y va avec les votes :

• Le Concurrency TS (N4501) : pas d'opposition
• Le Parallelism TS (N4505) : pas d'opposition. Petits échanges d'ordre administratif : ce document était prêt à Urbana, la rencontre précédente, mais ISO a bougé si vite pour offrir de publier que tout le monde a été pris par surprise et WG21 avait mis les freins pour qu'on soit certains que tous avaient bien compris les enjeux
• Un const-propagating smart pointer wrapper (N4388) : pas d'opposition
• Fonction make_array() (N4391) : pas d'opposition
• Le multidimensional bounds offset and array_view (N4512) : le feedback qui a été soumis n'a pas été incorporé. Jeffrey Yasskin dit qu'on le met dans un TS en sachant que c'est imparfait, et s'attend à des correctifs avant la publication du TS. Il y a des objections. Il y a beaucoup d'abstentions, et le vote est très serré. Non. On va se reprendre à Kona. À lire d'ici là, donc
• Le Source-Code Information Capture (N4519) : pas d'opposition
• Le C++ Detection Idiom v2 (4502) : Walter Brown explique qu'il s'agit d'un pattern de programmation et qui est la suite de void_t. L'idée de le mettre dans un TS est de laisser les gens l'apprivoiser, puis on l'enverra dans C++ 17 si on devient confortables. Pas d'opposition
• Fusionner les Library Fundamentals V1 et V2 (voir 4521) : pas d'opposition.
• Le tuple_size primary template should be defined (N4386) : Nevin Lieber dit qu'on ne l'a pas vu passer sur le « Reflector » et n'a pas été discuté cette semaine, alors il aimerait qu'on ne prenne pas position. Jens Maurer indique que c'est passé en avril. Alisdair Meredith dit que ça a été discuté à Cologne. On la retire
• Le improving pair and tuple (N4387) : Mike Spertus dit attendre celle-là depuis longtemps. Pas d'opposition
• Le bool_constant (N4389) : pas d'opposition
• Le shared_mutex for C++ 17 (N4508) : pas d'opposition
• Le LWG 2228 missing SFINAE rule (N4366) : pas d'opposition
• Le minimal incomplete type support for standard containers (N4510) : pas d'opposition. Cependant, le lien sur le site de Straw Polls est incorrect

On discute enfin du conditionally-supported special math functions v3, version amendée (N4337). Ouf. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4437.pdf

Marshall Clow fait un retour historique sur cette question. Le IS pour les fonctions mathématiques spéciales remonte à loin. Walter Brown a écrit un texte sur le support conditionnel de ces fonctions en C++. Il y a eu beaucoup de débats sur le sujet cette semaine, plusieurs votes. On a décidé de venir devant la communauté entière, initialement avec l'idée en enlevant le volet obligatoire. Cependant, aujourd'hui, on a choisi de proposer un support obligatoire de ces fonctions dans le standard.

Question : doit-on voter aujourd'hui pour renouveler l'ancien standard non-appliqué?

Réponse : ça peut attendre à Kona

Commentaire : Dinkumware a implémenté ceci, ça a été fameusement difficile, et on a réussi. J'ai commis l'erreur de dire aux gens de WG21 à quel point ça avait été ardu et les gens n'ont plus envie de l'implémenter. Toutefois, il y a maintenant une option tierce, soit une implémentation à code ouvert de ce standard. Je pense que ça change la dynamique dans ce dossier

Commentaire : je maintiens une version d'un produit à code ouvert et c'est pas simple

Question : doit-on avoir une implémentation de cette bibliothèque dans une implémentation Free-Standing de C++?

Réponse : non

Commentaire : la communauté scientifique aime C++, et ces fonctions sont celles dont on a besoin pour faire notre travail. Supporter notre communauté rapportera à C++ tout entier

Commentaire : je ne suis pas opposé à un support conditionnel. Un support obligatoire me rend moins heureux. Le niveau technique des clients et des bogues à régler va nous vider de notre énergie. On préférerait la livrer si cela nous semble raisonnable d'un point de vue commercial. Ça coûte cher de supporter ce genre de truc

Commentaire : je ne suis pas opposé à ceci, mais je n'aime pas que ce soit dans <math.h> car on ne le contrôle pas. Si on le place dans <cmath>, que nous contrôlons, c'est Ok

Commentaire : j'ai parlé à bien des gens car j'ai vu venir ces débats toute la semaine. Quel est l'effet d'un support conditionnel? On a des trucs comme ça dans et ça se teste avec des macros. Par contre, ceci est un gros truc, pas un petit truc. Le statu quo actuel est déjà le support conditionnel. La motion sur la table est un support inconditionnel, ce qui est autre chose. Je ne sais pas combien d'implémentations du IS sont dans std sur la planète.

Réponse :il y en a une par Dinkumware

Commentaire : je suis conscient de l'importance de ceci pour la communauté scientifique. Je pense que ce qui est là peut aussi nous apporter des avantages dans plusieurs autres domaines.

Commentaire : c'est utile pour la civilisation toute entière, bien sûr, mais il existe des implémentations de ce truc et on sait où aller les chercher. Je pense aux coûts pour les petits vendeurs, dans le domaine des systèmes embarqués par exemple : si une entreprise de la taille de Microsoft trouve ça coûteux, que feront les plus petits vendeurs?

Commentaire : ce ne sont pas des bonbons, ce sont des fonctions mathématiques pertinentes et utiles, faciles à utiliser pour les spécialistes. Elles sont clairement spécifiées mais difficiles à implémenter. Je pense que ça a sa place dans le standard. Je ne suis par contre pas sûr qu'on est prêts à procéder. Si un individu avec quelques PhD bien se plaindre qu'on a un bit incorrect, on sera bien mal pris de l'aider. Je pense qu'on devrait y aller graduellement, et développer au passage l'expertise requise pour éventuellement le supporter

Commentaire : pour nous, un support conditionnel est une mauvaise chose. Je sais que c'est la situation actuelle. Ma communauté m'a envoyée ici parce qu'elle veut savoir si les millions de lignes de code que nous avons aujourd'hui fonctionnera encore dans dix ans. On n'utilise que du code standard pour cette raison, et on ne peut utiliser les fonctions mathématiques spécialisées pour cette raison. Avoir ces fonctions sera un gros avantage à nos yeux

Commentaire : je suis d'accord pour dire que le statu quo ressemble à la situation actuelle. Je reconnais le risque d'un C++ modulaire. Je crains qu'une entreprise réalisant un contrat gouvernemental se trouve coincé à offrir ces fonctions et doive imposer à ses fournisseurs d'outils de supporter ceci

Commentaire : je suis surpris qu'on ait collectivement discuté de support conditionnel d'outils de nature scientifique, des choses qui comptent, mais qu'on estime correct discuter de trucs simples comme optional

Commentaire : on parle de 21 fonctions. Boost en a une partie. Il est possible de réduire les coûts d'implémentation de cette bête. Ces fonctions sont très importantes pour mon entreprise, pour les statistiques, les calculs de type « haute performance », le domaine financier, etc. Et ce sont des trucs que vous ne voulez pas implémenter vous-mêmes. Je pense qu'on devrait considérer très sérieusement de les supporter de manière inconditionnelle. Dans bien des contrats, on exigera un langage de programmation avec un numéro de standard ISO. Le support conditionnel n'est pas à notre avantage, surtout pour 21 fonctions bien documentées et bien comprises par leurs clients

Question : est-ce que la communauté C a examiné cette question?

Réponse : on ne révise pas le standard C pour le moment, alors non

Réponse : ils ont fait ça avant nous!

Réponse : c'est un TS pour C 11

Commentaire : le nombre de fonctions n'a rien à voir avec la complexité d'implémentation. C'est des années de travail et de tests. Si on indique mandatory, on impose une pression sur le vendeur; si on le garde optionnel, ça devient une décision de marché. Les usagers peuvent choisir le fournisseur de leur choix. Le marché peut changer

Question : quelle est la licence pour l'implémentation à code ouvert? Aussi : devrais-je la vouloir implémentée sur mon téléphone?

Commentaire : le problème du support conditionnel est que ça nous empêche de les utiliser. Elles ne sont pas standards au sens où nous l'entendons

Commentaire : je pense qu'on devrait voter

Commentaire : le libellé du vote tel qu'écrit me semble correctement écrit.

Question : j'aimerais savoir la réponse à la question pour la licence

Réponse : pour la version du TS, c'est une licence GPL v. 3 avec une retouche pour faciliter la diffusion non-virale. La version Boost est sous licence Boost

Commentaire : j'ai entendu plusieurs nouveaux arguments, et l'argument pour une inclusion non-conditionnelle me porte à vouloir réfléchir. J'aimerais digérer cette nouvelle information et me faire une tête. Est-on pressés? Je pensais que nous offrions un excellent support à la communauté scientifique et je suis un peu secoué

Commentaire : j'aimerais qu'on vote et qu'on se permettre de revisiter la question ultérieurement si nous l'estimons pertinent

Commentaire : je n'achète pas l'argument selon lequel un support conditionnel est un obstacle à l'adoption. On a déjà une situation de support variable pour plusieurs caractéristiques du langage selon les implémentations

Commentaire : on n'a pas à juger des décisions d'entreprise de nos clients

Commentaire : si on l'adopte, il est probable que plusieurs implémenteurs se mettront à l'implémenter rapidement. Sur la base de ce que j'ai entendu aujourd'hui, je vais supporter fortement la proposition

Commentaire : j'ai essayé de ne pas parler. Peu importe la décision prise aujourd'hui, je pense que nous sommes parvenus à informer les gens sur place d'une préoccupation bien réelle de la communauté scientifique et numérique. Ce que nous n'avons pas clairement exprimé, c'est pourquoi ce sont ces fonctions qu'il nous faut (il trace un historique de cette question). Adopter ces fonctions dans le standard est un message que nous envoyons à la communauté qu'elle n'est pas un « enfant bâtard ». (note personnelle : oups! Ça dérape). Je sais que je suis hyperbolique parfois. Je ne reviendrai pas sur le sujet, je passe la torche à la communauté, qui vous envoie (à ma surprise) un message bien plus clair que je ne l'aurais cru

Commentaire : je m'objecte fortement à ce que ce vote puisse être considéré comme un camouflet à une communauté

Commentaire : désolé d'avoir ri, mais j'ai trouvé le choix du mot « hyperbolique » délicieux dans les circonstances (rires!)

Commentaire : je ne pense pas qu'on puisse parler d'un fort consensus

Commentaire : je suis légèrement contre cette proposition, mais j'espère voter à nouveau dans le futur et être pour. Je suis fortement contre le support conditionnel, par contre. Je pense que c'est la pire des situations

Commentaire : je ne suis pas convaincu que le vote a vraiment opposé les usagers et les implémenteurs

Commentaire : le deuxième vote qui s'annonce, à propos d'un support conditionnel, me semble différent du statu quo (il lance une boutade qui fait rire les gens, mais je l'ai manquée)

Commentaire : si on ajoute un support conditionnel de ceci dans un TS, il y aura des réactions et je veux diffuser la nouvelle plus largement, question d'avoir le point de vue des gens hors de la salle et éviter une explosion dans 18 mois

Marshall Clow (je le nomme ici car il parle à titre officiel et technique pour LWG) : je veux rappeler aux gens dans la salle que les vendeurs n'ont pas le droit d'ajouter des noms dans std à leur convenance. Ainsi, si on n'a pas de support conditionnel, ces fonctions devront être hors de std

Commentaire : je crains qu'on ne crée un précédent en ayant une bibliothèque avec support conditionnel

Commentaire : je ne comprends pas exactement ce que l'on mettrait dans le sondage envoyé à tous

Réponse : le document entier, pour éviter les écueils dans le futur

Commentaire : je crains que les implémenteurs ne votent pour ceci qu'en pensant que c'est moins pur que le vote précédent. Si vous ne voulez pas l'implémenter, votez contre. Ça ne sert à rien d'envoyer un faux message à la communauté

Commentaire : on a quelques exemples de support conditionnel. Le over-alignment, par exemple. La collecte d'ordures aussi. C'est là mais ça peut être des noop

Commentaire : j'aimerais vraiment qu'on remette tout ça à Kona. Je suis encore sous le choc de la force des échanges cet après-midi

Commentaire : je pense qu'il faudrait voter aujourd'hui. Je comprends que [...] est au bout de ce qu'il était disposé à faire dans ce dossier. Nous avons au moins quatre Emeritus aujourd'hui, ce qui est exceptionnel, et je ne suis pas sûr qu'on ait cette représentation à Kona

Commentaire : un support conditionnel crée les noms et met le support du texte entre les mains du WG21. Un non-support n'a pas ces qualités

Question : quelle est l'interprétation de notre vote?

Réponse : c'est un consensus, mais pas un consensus fort.

Commentaire : c'est du deux pour un si on compare les oui et les non

Commentaire : je comprends, de l'interprétation qui est faite ici, qu'on donne beaucoup de poids aux implémenteurs dans le vote

Commentaire : je serais nerveux de voir ce vote comme un consensus. C'est la décision de [...] mais je suis à l'aise avec son interprétation

Commentaire : sur la base de l'interprétation de [...], on pourrait implémenter toutes ces fonctions et retourner NaN. Ce serait une implémentation, mais elle ne serait pas très bonne (on rigole).

Commentaire : j'aimerais qu'on remette ça à Kona. Je ne nous vois pas faire beaucoup de progrès.

Commentaire : je propose que l'on reprenne le premier vote étant donné les échanges depuis

Ouf. Marshall Clow va se rasseoir et on l'applaudit.

Clark Nelson : on examine les prochaines rencontres

• Kona en octobre 2015
• Aux É.-U. en février 2016? Ceci serait ajout, et aurait lieu soit dans le Sud de la Californie, soit en Floride
• Oulu (Finlande) en juin 2016
• Aux É.-U. en octobre 2016

On ajourne vers 17h15

On compte faire de la priorisation de « issues » ce matin. Jens Maurer fait remarquer que pour les coroutines, il y a un risque que la reprise d'une coroutine après un point d'arrêt soit faite dans un thread distinct du thread original, ce qui peut compliquer (c'est le moins qu'on puisse dire!) le concept de happens-before puisqu'on perdrait la relation sequenced-before.

On reprend les discussions sur l'item 2067. Qu'est-ce qui, dans le texte normatif, permettrait de ne générer que des templates à zéro paramètres? Le code qui a mené à la détection du problème est :

#include <utility>
template <template <class...> class T, class...X>
   struct Part
   {
      template<class...Y>
         using type = T<X..., Y...>;
   };

template <template <class...> class T, template <class> class U>
   struct UCompose
   {
      // Not ok!
      template <class X, class...Y>;
         using type = T<U<X>, Y...>;
      //// Ok!
      //template<class X>
      //   using type = T<U<X>>;
};

int main()
{
   using IsInt = Part<std::is_same, int>;
   static_assert(IsInt::type<int>::value, "");    // Ok!
   using IsIntD = UCompose<IsInt::type, std::decay_t>;
   static_assert(IsIntD::type<int&>::value, "");  // Not ok.
}

Par contre, semble que ceci fonctionne :

template <template <class...> class T, class...X>
   struct Part
   {
      template <class...Y>
         struct result
         {
            using type = T<X..., Y...>;
         };
   };
template <template <class...> class T, template <class> class U>
   struct UCompose
   {
      template <class X, class...Y>
         using type = typename T<U<X>, Y...>::type;
   };
int main()
{
   using IsInt = Part<std::is_same, int>;
   static_assert(IsInt::result<int>::type::value, ""); // Ok!
   using IsIntD = UCompose<IsInt::result, std::decay_t>;
   static_assert(IsIntD::type<int&>::value, "");
}

Le standard dit If every valid specialization of a variadic template requires an empty template parameter pack, the template is ill-formed, no diagnostic required, mais il y a clairement un intérêt à la manoeuvre.

Item 2068 : dans un cas comme ceci, le destructeur de B devrait pouvoir être défini implicitement, mais le texte du standard ne le spécifie pas :

struct A { virtual ~A(); };
struct B : A {};
int main()
{
   A *p = new B;
   delete p;
}

Jason Merrill fait remarquer qu'on touche ici aux optimisations de dévirtualisation, et que ça entraîne du plaisir d'accès aux symboles cachés dans des bibliothèques partagées. Jens Maurer demande si les destructeurs sont des citoyens de seconde classe pour fins d'optimisation par dévirtualisation. Jason Merrill dit que oui, essentiellement. Richard Smith estime qu'on ne devrait pas être obligés de le définir si on ne l'estime pas nécessaire. Richard Smith dit qu'on a des cas pour d'autres fonctions aussi. Ici, la fonction est odr-used parce qu'elle est virtuelle sans être pure.

Item 2069 : les destructeurs ont-ils des noms? Non, mais on a une phrase qui laisse entendre que oui. Faut la réécrire. Hubert Tong fait remarquer qu'on pourrait avoir plusieurs noms pour un même destructeur; Richard Smith signale que c'est le cas avec les opérateurs de conversion. Clairement, dans 3.4.3.1, on peut lire A destructor's name is looked up... qui est incorrect.

Item 2070 : on l'a couvert indirectement plus tôt cette semaine (question de lookup de noms d'espaces nommés), mais c'est plus subtil car on examine des questions d'alias dans les noms de constructeurs lorsqu'ils sont complexes (noms de templates, espaces nommés, etc.). On a une résolution pas si mal, mais il se peut que ça prenne des retouches ultérieures si on frappe des cas étranges qui nous ont échappé. Jason Merrill pense que ça recoupe deux cas semblables qui lui ont été assignés, soit 156 (fonctions de conversion) et 399 (destructeurs et « name » lookup).

Item 2071 : faut empêcher un typedef sans déclarateurs comme :

typedef struct X { }; // manque un nom entre } et ;

...qui est valide (on n'a rien pour l'empêcher) mais n'a pas de sens et devrait être diagnostiqué. Jonathan Caves dit à la blague qu'interdire ceci briserait Windows Plus sérieusement, ça ne fait rien mais faudrait l'interdire.

Item 2072 : il manque un peu de terminologie pour les paramètres avec valeur par défaut dans les méthodes génériques. À titre terminologique, semble qu'une méthode d'un template soit un temploïde.

Item 2073 : la restriction empêchant les exceptions d'allouer dynamiquement de la mémoire pose problème dans une situation multiprogrammée. Lever bad_alloc entre threads pourrait impliquer une forme d'allocation dynamique de mémoire. Richard Smith pense qu'on ne devrait pas contraindre les implémentations ici. On va y réfléchir, c'est une priorité 1. Hubert Tong pense que c'est une question de qualité d'implémentation, mais Aaron souligne qu'on pourrait causer des ennuis aux gens qui écrivent des allocateurs.

Item 2074 : une classe interne à une fonction générique est un type dépendant seulement si elle contient un objet de ce type, mais c'est obscur dans la pratique. On a des considérations d'alignement aussi : est-ce que le recours à une clause alignas rend un type dépendant dans un tel cas? Faudra préciser.

Jason Merrill dit qu'un des exemples contient un type dépendant et nécessite un typename :

template<int N>
   struct Y
   {
      typedef int type;
   };
template<int N>
   void h()
   {
      struct alignas(N) X {};
      Y<alignof(X)>::type z;   // <-- ici
   }
void i()
   { h<4>(); }

Item 2075 : question normative sur les conversions impliquant un tableau de N instance de x. La résolution proposée est adoptée. Ok.

Item 2076 : pas fin ici. On parle d'initialisation avec liste et de paramètres aux constructeurs. Richard Smith souligne que quand Clang a implémenté la résolution à 1467, ça a tout cassé chez eux. Ceci devenait incorrect :

struct A { A(int); };
struct B { B(A); };
B b{{0}}; // ambigu

Ceci aussi :

struct Params { int a; int b; };
class Foo
{
public:
   Foo(Params);
};
Foo foo{{1, 2}}; // Foo(Params) ou Foo(Foo&&)

La résolution propose est de préciser une clause préférentielle pour lever l'ambiguïté. C'est une priorité 1.

Item 2077 : la résolution à 1604 a brisé ce qui suit :

struct A {};
struct B { operator const A() const; };
void f(A const&);
void f(A&&);
int main()
{
   B a;
   f(a); // choisit A&& et échoue
}

... et ceci :

std::vector<A> va;
B b;
va.push_back(b); // rejeté. Pas cool

La résolution ici n'est pas claire. Jason Merrill pense qu'on a corrigé celui-ci en ne considérant pas les conversions « maison » et réfère à 5.2.2 p.1 et à 8.5.3 p.5. Priorité 1.

Item 2078 : calvaire. L'exemple dit tout.

struct file_stat : ::stat {    // the class
   file_stat() : ::stat{} {}   // the function
};

Jason Merrill dit, presque à la blague « oui, NAD, c'est vrai que ça peut donner des résultats surprenants, vous avez raison ». On s'entend là-dessus.

Item 2079 : bogue de grammaire avec [[ pour débuter une annotation si on veut permettre des fragments de code d'apparaître à cet endroit. John Spicer fait remarquer que c'est un bogue qui nous vient du futur. Aaron va le faire.

Item 2080 : exemple avec bris, mais Richard Smith va s'en occuper. C'est l'union vide qui ne fonctionne pas :

union U
{
   int x = 0;
   union { };
   union
   {
      int z;
      int y = 1; // error: initialization for second variant member of U
   };
};

Hubert Tong y voit un problème; il reconnaît par contre que l'analyse proposée par la résolution est Ok.

Item 2081 : on en a discuté plus tôt cette semaine, indirectement.

Item 2082 : le texte du standard empêche ce qui suit, qui devrait être légal :

void foo(int a = decltype(a){});

Il y a des retouches à faire à quelques endroits pour régler ceci, par contre. Ça laisse transparaître une nuance entre used et odr-used.

Item 2083 : avec l'item 1741, on a des cas d'odr-used non-désirés qui briment des cas de constexpr qui seraient, autrement, légaux. C'est une priorité 1.

Item 2084 : ce qui suit est accepté par la plupart des compilateurs mais, au sens strict, n'est pas permis. On pense que le texte est trop restrictif avec NSDMI (Non-static Data Member Initialization). L'idée ici est que le constructeur par défaut de U serait =delete « normalement » mais il n'y a pas de bonne raison pour que ce soit le cas.

struct S
{
   S();
};
union U
{
   S s{};
} u;

Ici, le NSDMI est en fait l'équivalent d'un constructeur par défaut « maison ».

Item 2085 : on a un exemple qui n'est plus correct de constructeurs paramétriques avec paramètres munis de valeur par défaut. La règle est encore correcte, mais pour les méthodes autres que les constructeurs, alors faut retravailler l'exemple.

Item 2086 : nuances entre le odr-use d'une référence, son contexte d'utilisation et son initialisation. C'est très particulier comme exemple.

Item 2087 : un cas comme i<<0 pour i entier et négatif résulte en un comportement indéfini. Richard Smith pense que la règle est peut-être correcte telle quelle, et suggère que SG12 le regarde au moins. Priorité 1. Hubert Tong demande si les conversions arithmétiques impliquées pourraient être la source du comportement indéfini, mais Richard Smith indique que ces conversions sont implementation-defined.

Item 2088 : on a une règle ambiguë dans le cas de certaines conversions où plusieurs cas peuvent réussir. L'exemple est pervers :

template <typename T>
   struct A
   {
      struct typeA { };
      struct typeB { };
      using convTyA = T (*const &&)(typename A<T>::typeA);
      using convTyB = T (*const &)(typename A<T>::typeB);
      operator convTyA();
      operator convTyB();
   };
template <typename T>
   void foo(T (*const &&)(typename A<T>::typeA));
template <typename T>
   int foo(T (*const &)(typename A<T>::typeB));
int main()
{
   return foo<int>(A<int>());
}

C'est une priorité 1. Hubert Tong pense que ça rejoint l'item 1187.

Item 2089 : le standard dit que ceci est incorrect (ça devient operator+(int*,ptrdiff_t) une fois résolu, et on n'a pas le droit de remplacer ça pour des raisons que je vous laisse imaginer ) mais c'est accepté par certaines implémentations :

struct Adaptor { Adaptor(int); };

struct List { };
void operator +(List &, Adaptor);

struct DataType
{
   operator int *() const = delete;
   operator List &() const;
};

struct Yea;
struct Nay { int theNaysHaveIt; };

template <typename T, typename U>
   Yea addCheck(int, T &&t, U &&u, char (*)[sizeof(t + u, 0)] = 0);
template <typename T, typename U>
   Nay addCheck(void *, T &&t, U &&u);

void test(DataType &data)
   { (void)sizeof(addCheck(0, data, 0.).theNaysHaveIt); }

Hubert Tong a une résolution à proposer, mais pas ce matin.

Item 2090 : question de types non-dépendants dans un contexte où ils deviennent, en apparence, dépendants. Richard Smith pense qu'il manque un mot dans la formulation. La définition de non-dependent member nous fait fouiller dans le standard. On sait ce qu'on veut; faudra l'écrire. On peut même carrément supprimer le paragraphe offensant; semble que ce soit le chemin choisi pour résoudre celle-ci.

Item 2091 : l'exemple est pervers. Je ne le voyais pas, mais :

template <int &> struct X;
template <int &N> void f(X<N>&);
int n;
void g(X<n> &x) { f(x); }

On utilise l'adresse de la variable globale n, techniquement, pas sa valeur, alors c'est Ok. Ici, on a une règle qui ne donne pas le bon résultat mais c'est corrigeable sur le plan terminologique. On est trop stricts. Faudra trouver une terminologie acceptable.

Au retour, Hubert Tong dit s'être renseigné sur la covariance des coroutines. Pensez-y un peu… On génère du code côté bibliothèque alors ça a des conséquences divertissantes sur la générations du code.

Item 2092 : la plupart des implémentations refusent ceci :

template <class T = int> void foo(T*);
void test()
{
   foo(0);   // #1 valid?
   foo<>(0); // #2 valid?
}

...mais il semble que ça devrait être raisonnable, au moins dans le cas #2. Clairement, foo<int>(0) est Ok. On a traité un cas très semblable plus tôt cette semaine.

Item 2093 : dans les clauses catch, on permet de qualifier les gestionnaires sur un pointeur ou une référence mais pas sur un pointeur ou une référence sur un membre d'instance. Cependant, plusieurs implémentations le supportent. Il manque un cas dans le standard, alors c'est une écriture mineure et de priorité 0 selon JM. Richard Smith se demande si ça peut briser l'ABI de gestion d'exceptions de quelqu'un. Jason Merrill simplifie : ça brise la compatibilité avec C. Hubert Tong explique ce que fait le compilateur d'IBM, et il lui faut aller vérifier des détails. Il se peut que le changement soit mineur.

Item 2094 : la clause 12.8 parag. 25.2 rend certains constructeurs non-triviaux avec un membre d'instance volatile, ce qui brise l'ABI du IA-64. On questionne la distinction entre type trivial et type trivialement copiable. Hubert Tong dit en riant que depuis qu'on utilise le mot trivial, plus rien qui utilise ce mot n'est trivial. Priorité 1.

Item 2095 : comment devrait-on capturer par copie une entité qui est une référence sur une rvalue vers une fonction? Ça peut intervenir avec des λ. Richard Smith pense que la rvalue reference devrait devenir une lvalue reference dans ce cas. Une retouche de formulation sera nécessaire.

Item 2096 : on serait trop contraignants pour la définition de type littéraux non-volatile, du moins dans le cas des union. Richard Smith est d'accord : on pourrait avoir un constexpr avec un tel type, et cette écriture nous bloque. Richard Smith fait remarquer que si on a un type dont le constructeur n'initialise rien, il pourrait être raisonnable de le considérer comme un type littéral,et il serait raisonnable de le construire constexpr dans ce cas. Mike rappelle qu'un constructeur constexpr doit initialiser tous les membres. Ok, on va demander d'initialiser « au moins un » membre au lieu de « tous » les membres dans le cas des union. Richard Smith dit qu'on va faire semblant que les union anonymes n'existent pas .

Item 2097 : semble qu'il soit présentement interdit d'écrire ceci :

auto bail = [] () [[noreturn]] { std ::exit(1); };

... à cause du [[noreturn]]. Ça semble pourtant raisonnable. Jonathan Caves dit que Gabriel Dos Reis aimerait que cette notation s'applique pour ses démarches de contrats. La position du [[noreturn]] ici est indicative qu'on voudra éventuellement utiliser les noms passés à la λ dans le contrat. On envoie ça à EWG..

Item 2098 : est-ce que uncaught_exceptions() est « par thread »? Le standard ne le dit pas, mais faudrait.

Item 2099 : bogue de grammaire ici (confusion entre initialisation par accolades et member-declarator).

... et je dois quitter. Snif parce que c'était diablement intéressant, mais j'ai vraiment hâte de revoir ma belle et mes chiboukis. Départ bien sympathique où on m'a dit souhaiter me revoir à Kona en octobre; c'est sûr que ça m'intéresse, mais ça va dépendre de facteurs externes à ma volonté.