xryl669 a écrit 106 commentaires

MD5, c'est le futur, c'est rapide, peut être pas autant qu'un bon CRC-32, mais bon, il faut quand même que l'ordinateur rame un peu lorsqu'il signe un very important mail sinon l'utilisateur pensera que c'est bidon le cryptage.

Vu le code, ça semble orienté vers de la crypto-monnaie uniquement.

Désolé pour la réponse tardive. Haraka n'est pas un serveur mail classique comme Procmail. C'est un outil de pre-processing de mail. Il y a des dizaines de fonctions pour préprocesser les mails qui entrent, les filtrer, les aliases, les modifier, etc…

Tu peux par exemple, passer un filtre anti-spam (classique) mais dans ce cas, activer le mode tarpit qui va mettre très longtemps à répondre (genre 1 octet par seconde), et ainsi retarder fortement le spammeur. Tu peux faire les alias comme j'ai indiqué, faire du DKIM verify avec action paramétrable si ça échoue, du DKIM sign, …

L'une des options intéressantes c'est de récupérer les mails pour les stocker en BDD, pour faire un service mail qui n'utilise pas les classiques IMAP mais au contraire JMAP ou autre. Bref, c'est une boite à outils, à toi de faire une application avec.

C'est un peu l’œuf et la poule ici malheureusement.

On a d'un côté Weboob qui a déjà fait un travail colossal pour unifier des interfaces très différentes entre les banques, et de l'autre une équipe qui fait un travail très prometteur mais qui a décidé de faire tout (le travail) dans le browser.

Résultat, soit il faut tout réimplémenter les "konnectors" dans l'API Cozy (c'est à dire ré-écrire weboob qui est en python en JS), soit faire un gros hack dans Weboob (c'est à dire faire un serveur HTTP en python avec une API, et écrire un "konnector" dans Cozy pour cette API). Mais ça veut dire configuration des comptes via ligne de commande… pas très user friendly.
Le travail de Budget Insight, c'est justement ça: une API au dessus de Weboob. Si Cozy rendait open-source leur connecteur avec cette API, alors un développeur qui la réimplémenterait en open-source mettrait Budget Insight sur la paille (je pense que c'est pas très cool vu le travail fourni par BI).

Honnêtement, je trouve que les choix qui ont été fait amènent à une situation de deadlock où les deux alternatives (tout réimplémenter, banque par banque ou faire un konnector vers une API http serveur Weboob) sont mauvaises.

J'ai installé une instance Cozy pour l'application Cozy Bank et j'ai été super déçu de me rendre compte que les connecteurs vers les banques ne sont pas fonctionnels ou disponibles pour l'auto hébergé.

Pour moi, si c'est pour avoir un n-ième fournisseur d'agrégateur bancaire propriétaire, j'utilise l'une de mes banques, elles proposent toutes la fonction maintenant.

C'est déjà le cas, tu peux l'activer dans les options (ce que j'ai fait, ça marche nickel)

Personnellement, vu le problème des a+b@domain.com qui ne sont, ni privés (n'importe quel programmeur peut décider de supprimer tout ce qui est entre + et @ pour avoir l'email source), ni acceptés partout, je suis tombé sur la solution open source Haraka.

Ça marche très bien. On peut choisir le format de la redirection (par exemple a.b@domain.com qui eux, sont acceptés partout, ou simplement b@siteinconnu.domain.com).

Ça ne consomme rien en ressources, et on peut faire des tas d'analyses, rejet des spams etc…

J'ai fait un tutoriel pour l'installer:
https://steemit.com/mail/@xryl669/forwarding-email-to-your-domain-to-your-personal-email-box-anti-challenge-1

Ça bouge pas mal côté FPGA et Opensource ces derniers temps.

Projet de "GCC" du FGPA: (par reverse engineering des architectures & outils)
https://symbiflow.github.io/

Nouveau FPGA (chinois) pas cher:
https://hackaday.com/2019/11/03/the-5-fpga/

Il est considéré qu'une dose de 20ppm de CO est la limite acceptable. Si l'on regarde la courbe du capteur MQ 135, cela correspond à une variation de 12% de la résistance du capteur (autant dire, pas grand chose).
Le problème c'est qu'une telle variation est obtenue avec 15ppm de CO2 dans l'air, c'est à dire que si tu mets un seuil trop faible pour la détection de CO, le simple fait d'allumer une bougie dans la pièce le fera franchir à cause du CO2.

C'est d'ailleurs le problème de ce genre de capteur, qui ne font aucune différence sur les composés qu'ils détectent.

Si tu regardes les détails des 3 failles, la première force l'ESP8266 à rebooter (ce qui n'est pas forcément un soucis de sécurité, seulement tu perds ton périphérique).
Les deux autres nécessitent que l'ESP8266 soit connecté en EAP (cas très très rare chez les particuliers).

Dans la pratique, ce n'est pas Hiroshima.

Non, ce n'est pas le cas. Le CO2 n'est pas détectable par les capteurs bon marché. Ce qu'ils détectent, c'est les particules de la fumée (donc il faut que ça "fume"). Il n'y a pas d'arnaque car ils sont bien vendus comme détecteur de fumée.
Leur technique de détection varie, mais c'est grosso modo soit la transparence de l'air qui est mesurée (lumière/capteur) ou pour les plus avancés ils détectent la variation électrique d'une source d'ions (souvent générés par un composé radioactif) qui sont perturbés par la fumée.

C'est quand même vachement simple de détecter ce genre de cas en C++.

class A
{
private:
    A() { throw new you_are_a_donkey_exception(); }
};

// Si ça, ça compile, c'est qu'il y a un soucis dans tes macros
A a;

Essaye OnlyOffice. Franchement, ça passe dans 99% des documents DOCX sans problème, le 1% restant, c'est dû aux polices qui ne sont pas présentes sur mon ordinateur, ou des intégrations OLE anciennes (ce qui est de plus en plus rare).

Par contre, avec LibreOffice, ouvrir un DOCX fonctionne dans quoi, peut être 1% des cas. Dès qu'il y a une illustration, c'est mort. Dès qu'il y a une numérotation automatique (genre 1. Titre 1, 1.1 Titre 2, etc…), c'est mort. Dès qu'il y a une table des matières c'est mort, etc…

Je ne suis responsable chez eux, mais dans ma boite, si le support est aussi nul, je ne l'active pas du tout, car ça dessert le logiciel qui est par ailleurs excellent, les utilisateurs ne retiennent que "ça ne marche pas".

Enfin, même si le document s'ouvre "à peu près" correctement, si tu l'enregistres en DOCX, plus aucun logiciel ne saura l'ouvrir comme il faut (pas même LibreOffice, ce qui montre que leur test sur ce type de format sont assez limités).

Après, c'est l'expérience dans la vraie vie, en étant pragmatique. Maintenant, oui c'est sûr ODF c'est plus "simple", c'est pas Microsoft, c'est … mais c'est surtout inutilisé.

Je suis passé à OnlyOffice il y a maintenant 2 ans, et je n'entends plus personne me poser la question de quel logiciel j'utilise (sous entendu, le document est cassé), voir me faire des remarques comme quoi les doc ne marchent plus. Et je peux te dire que j'en écris/relis/corrige des documents…

Ouais, enfin bon. Si tu as déjà regardé un document de dépot de brevet, tu as vu qu'il contient des schémas, des liens, des références, des tables, etc… Je te mets au défi de me montrer 2 logiciels sachant gérer de l'ODT sans casser la présentation. Pire encore avec le DOCX dans un logiciel dont le modèle de document est calqué sur l'ODT.

Dans la pratique, il existe des soft opensource qui font du DOCX en natif (je pense à OnlyOffice), je vois pas pourquoi il faudrait que toutes les personnes qui travaillent avec l'INPI doivent passer par des logiciels différents, avec moins de fonctionnalité pour faire de "ODT", alors que leur base de travail quotidienne est en DOCX.

Je ne comprends pas les ayatollah de l'ODT qui estiment que leur format est supérieur. Je peux comprendre qu'un format propriétaire et fermé soit inférieur, soit parce qu'il faut passer à la caisse, ou parce qu'on ne sait jamais si le document s'ouvrira encore dans la version 2030 du logiciel, mais ce n'est pas le cas du DOCX.

Il existe des soft open source qui l'ouvre parfaitement (puisque le format n'est pas propriétaire, ni fermé) et qui sont gratuits. À nous de nous adapter au monde extérieur et pas l'inverse!

1. Oui
2. Oui
3. docx, xlsx, pptx c'est le format (de fait) utilisé partout où les gens travaillent avec les outils et pas sur les outils.

Complètement d'accord avec le dernier point. Onlyoffice est pour l'instant plus limité dans son interface que LibreOffice ou MS Office (malgré le fait qu'il supporte quasiment toutes les fonctions dans les fichiers OOXML). C'est la suite que l'on attendait en open source, car ça marche avec les autres sans les obliger à changer leurs habitudes.
Le format ODT, c'est beau comme un poème, c'est à dire en théorie, mais sans pragmatisme. C'est un format issu d'une suite office (StarOffice/OpenOffice) qui était peu utilisée, incompatible de fait avec le format "de facto". Impossible de faire tenir OOXML dans ODT, donc c'est à perte pour l'utilisateur qui veut utiliser le format.
Je tire mon chapeau au dev LibreOffice, mais depuis que j'ai compris qu'il n'y a aucune chance qu'un document DOCX soit ouvert correctement avec, c'est fini pour moi. Le seul cas où je démarre encore LO, c'est pour les tableurs car il supporte les fonctions statistiques (ex. régressions linéaires) nativement (alors que OnlyOffice n'a pas d'interface pour créer la régression linéaire, mais si elle est présente dans le fichier source, il sait la tenir à jour).
LO est aussi mieux optimiser pour les très gros tableaux (genre 50k cellules) alors que le code d'OnlyOffice rejette le document.

Oui, enfin bon. Quand tu vis dans la vraie vie, le format ODF (ODT/ODS/ODP) ça ne marche pas, le DOCX et XLSX et PPTX oui, et seul OnlyOffice le supporte correctement.

D'ailleurs, en réalité, le format DOCX est le plus problématique. Pour les tableurs et présentations, ça marchouille suffisamment pour que ce soit acceptable. Mais pas pour les documents textes.

Après avoir cherché pourquoi LibreOffice, malgré les années et les nombreux contributeurs était toujours incapable d'ouvrir un DOCX non basique correctement (et encore moins de l'enregistrer sans le casser), j'ai trouvé que le problème d'OO ou LO, c'est le modèle de document (qui a servi de base au format ODF d'ailleurs).

Ce modèle ne supporte pas toutes les fonctions que l'on retrouve dans le format DOCX. Du coup, lors de l'ouverture d'un DOCX il essaye de mapper le modèle DOCX sur son modèle inférieur, perdant, au passage, beaucoup d'information. Par exemple, DOCX supporte les ancres relatives d'un objet par rapport à un autre. ODS ne supporte que les ancres relatives par rapport à la page, ou au paragraphe. Dans un dessin dans Word, impossible donc de l'ouvrir dans LO sans que ça ne le casse (sans parler du reflow lorsque l'on ajoute/modifie le texte). Je peux t'en citer plein d'autre comme ça.

Donc, l'argument comme quoi la spec ODF est plus simple, oui et heureusement car elle ne fait pas tout ce que fait la spec XMLX.

Honnêtement, entre l'interface OnlyOffice et LibreOffice, y a pas photo, je préfère largement la première malgré le manque de fonctions dans le frontend (paradoxalement, leur backend est super puissant)

Je veux pas jeter la pierre, mais Microsoft a passé largement plus de temps et d'amélioration pour que son format de document soit vraiment adapté à un maximum de cas concrets (l'avantage d'être le seul à le maîtriser vs devoir se coller à une spécification) et je vois pas comment LO pourra le rattraper sauf à modifier le modèle de document, ce qui est quasiment impossible lorsque celui-ci est normalisé.

Donc, pour moi, c'est une beau mouvement de la part de Microsoft, en publiant son format XMLX et poussant pour que l'ODF soit normalisé (en l'état, donc inférieur), il a bloqué toute compétition car l'ensemble des efforts de la communauté open source est maintenant perdue à vouloir se "conformer" à une norme inférieure.

En plus "joli", il y a SimpleEmail disponible sur F-Droid. Il a une interface material (avec les swipe pour effacer les messages, aperçu des messages etc…). C'est à la base un fork de FairEmail, mais avec un contributeur plus à l'écoute des besoins des utilisateurs.

Comment vous faîtes pour Edge qui ne supporte pas les SSE ? C'est du polling ?

Justement, je suis assez étonné de cette réponse "même par une extension".
Vu que ladite extension serait téléchargée hors de l'app store: (exemple, le store des extensions de chrome qui ne passent pas par l'App Store)
1) Comment Apple peut-il le savoir ?
2) Même s'il le sait, actuellement, le texte qui interdit d'utiliser un autre moteur que Webkit est celui ci (de https://developer.apple.com/app-store/review/guidelines/ :)

4.4 Extensions

Apps hosting or containing extensions must comply with the App Extension Programming Guide or the Safari Extensions Development Guide and should include some functionality, such as help screens and settings interfaces where possible. You should clearly and accurately disclose what extensions are made available in the app’s marketing text, and the extensions may not include marketing, advertising, or in-app purchases.
[...]
4.7 HTML5 Games, Bots, etc.

Apps may contain or run code that is not embedded in the binary (e.g. HTML5-based games, bots, etc.), as long as code distribution isn’t the main purpose of the app, the code is not offered in a store or store-like interface, and provided that the software (1) is free or purchased using in-app purchase; (2) only uses capabilities available in a standard WebKit view (e.g. it must open and run natively in Safari without modifications or additional software); your app must use WebKit and JavaScript Core to run third party software and should not attempt to extend or expose native platform APIs to third party software; 

Je comprends, du 4.4 qu'une extension est autorisée si il n'y a pas de marketing, pub, ou achat in-app.
Du 4.7, puisque l'extension n'est pas l'application principale (dans ce cas), qu'elle n'est pas fournie via un store, qu'elle serait gratuite, ça devrait passer. Après je ne suis pas un avocat.

Autant, c'est génial pour android, autant sur iOS, on se sent un peu seul.
D'un côté Apple verrouille à l'utilisation de son webkit limité/ant, de l'autre on voudrait de l'alternative (libre en plus).
Est-ce que vous envisagez de faire une version pour iOS de Focus avec Gecko ? (par exemple, comme une extension téléchargeable ultérieurement, afin de ne pas être backboulé par la pomme lors de l'upload de l'application  ?)

Ce serait une petite révolution sur iOS, qui le mériterait bien.

La monnaie libre a opté pour un système permettant une symétrie spatiale et temporelle en appliquant simplement une vitesse de croissance du DU. l’augmentation quantitative du DU permettant "d'oublier" progressivement les DU anciens. Un système simple et parfaitement efficace pour limiter les effets d'accaparement. La conséquence étant (dans un cas théorique sans échanges) une convergence naturelle des comptes vers la moyenne de la masse monétaire par individu. Les comptes élevés comme les compte très faibles convergent selon une asymptote vers cette moyenne d'autant plus fortement qu'ils en sont éloignés.
Un peu comme un élastique demande de plus en plus d'efforts pour s'éloigner de son point d'attache (la moyenne), l'enrichissement demandera de plus en plus d'efforts pour s'en éloigner.

Autant mathématiquement, cela pourrait revenir au même, autant psychologiquement, ce n'est pas le cas.

Lundi:

• Bonjour, combien pour la baguette de pain ?
• 10 G

Mardi:

• Bonjour, combien pour la baguette de pain ?
• 15 G

Mercredi:

• Bonjour, combien pour la baguette de pain ?
• 21 G

Pour moi, en tout cas, je préfère quand les valeurs sont stables, je peux plus facilement les comparer, les appréhender, m'en souvenir. Dans le scénario ci-dessus, je te mets au défi de savoir, de tête, combien va te coûter ta baguette dans 93 jours. Auras-tu assez d'argent de côté si tu épargnes maintenant ? Est-ce que mettre de l'argent en banque sera rentable, vu la "croissance" de la monnaie ?

Bref, une valeur qui varie est insupportable.
Paradoxalement, une valeur de référence qui se dévalue lors de l'échange l'est beaucoup moins. La baguette vaudra toujours 10 T, seulement si tu veux la payer avec l'argent de ton salaire de l'année dernière que tu as mis de côté, il faudra débourser 11 T. Après tout, c'est exactement ce qui se passe actuellement avec la monnaie-dette, sauf que l'opération est validé à la transaction, au lieu de la lourdeur des impôts (déclarations, TVA, etc…). Le 1T de différence repart dans le circuit économique comme un "impôt", une TVR (taxe sur la valeur retirée).

À propos des échanges extérieurs, c'est tout à fait possible de faire des échanges avec d'autres monnaies d'ailleurs, mais le taux de change dépendra de la valeur non dévaluée de référence, c'est à dire une valeur qui ne fait qu'augmenter avec le temps. C'est un peu le principe que vous appliquez à l'intérieur du DU, mais uniquement pour l'extérieur.

La notion de liberté est très utopique. Aucun système ne peut fonctionner sans "la mort et les taxes", car l'humain livré à lui-même est cupide et peu prévoyant en général. Il est difficile de sous réserve de liberté, laisser des personnes sans protection santé, sans assurance civile, etc… Il n'y a qu'à voir au USA ce qui se passe.
Le problème des taxes et autres, c'est dans l'iniquité de leur création/évaluation et l'utilisation qui en sont faites. Si le système de monnaie dévalue en fonction d'un vote démocratique qui a spécifié les taxes (montants, objets, résultats) et donc le taux de dévaluation, il n'y a plus d'iniquité. Évidemment, il ne faut pas concentrer le pouvoir de vote dans les mains d'un nombre limités d'acteurs comme c'est le cas dans notre démocratie, mais justement, le pouvoir des ordinateurs/algorithmes c'est de garantir la justice et l'équitabilité du vote.

La toile de confiance est trop "statique", voire binaire. C'est déjà pénible à créer au début, j'imagine combien se serait difficile à virer sa confiance dans un individu (pour que tout le monde le fasse).
Mon idée est plus granulaire, une personne qui améliore le système par son comportement est sujette à un meilleur retour du système qu'une personne qui, sciemment, dégrade le système. C'est l'effet nudge.

Pour moi, une monnaie libre ne peut être basée sur les mêmes principes que les autres monnaies.
Philosophiquement, le libre c'est quoi ?
Pour moi, c'est, à la source, la combinaison du temps passé par le développeur/maker et de son expérience (acquise ou pas ailleurs) et la volonté de partager son Oeuvre avec d'autres.
Le "consommateur" profite de l'effort fourni par la source souvent gratuitement (l'un des critères fondamentaux) ou ouvertement (il peut modifier l'Oeuvre).

Un comportement que je trouve abject est celui qui profite de l'Oeuvre en la monétisant sans rétribuer la source, celui qui plagie la source sans apport intéressant, celui qui empêche la source de continuer son activité, etc…

Pour moi, une monnaie libre devrait permettre à des sources de vivre de leur activité tout en rendant la tâche plus difficile pour les "abjects".

Dit différemment, la monnaie devrait comprendre des mécanismes évitant les mauvais comportements et récompensant les bons.

Une des idées présentées pour cela, c'est d'associer une "réputation" à chaque individu utilisant une telle monnaie, réputation qui serait consommée pour faire des actions avec la monnaie et qui serait régénérée lorsque d'autres utilisent ou apprécie l'effort/l'Oeuvre de la source (c'est un peu l'idée de Steem, sauf que …)
En gros, je prends un risque en recommandant telle source ou effort, mais quand d'autres commencent à utiliser les Oeuvres en question, je suis remercié du risque pris par une amélioration de ma réputation.
Inversement, si je spécule comme un fou sans améliorer (je con-somme en détruisant), ma réputation va tomber en flèche, et j'aurais de plus en plus de mal à faire des opérations.

Ensuite, il faut que la monnaie se dévalue à chaque transaction (ce qui évite les "collectionneurs / cupides / riches") et également en fonction du temps (celui qui garde un trésor des années ne vaut plus rien car la transaction de "vente" dévaluera son bien en fonction de la durée d'acquisition). Le montant de la dévaluation repart dans le système et est, soit distribué entre les membres de manière équitable (c'est une sorte d'impôt à la "source"), soit utilisé pour les Oeuvres communes (écoles/formation, soin, bref tout ce qui sert au bien commun).
La dévaluation pourrait être modulée en fonction de la réputation (plus une personne a un comportement utile à la communauté, plus sa réputation est élevé et moins la dévaluation s'applique à elle).

Enfin, et c'est là le plus difficile, il faut éviter les échanges avec d'autres monnaies classiques (sinon les protections contre la spéculation / thésaurisation ne sert plus à rien). Je trouve aussi que c'est plus juste, car après tout, l'argent… c'est du temps. On a tous le même capital de temps, c'est la seule chose universelle qui a la même valeur partout sur Terre.

Enfin, il faudrait que tout comportement "abject" soit pénalisé par la perte de réputation voire le bannissement.

En gros, la TRM et le dividende universel donne de la valeur au temps (c'est bien en soit), mais pas en l'utilisation "utile" de ce temps. Le piège, c'est l'oisiveté, s'il ne faut fournir aucun effort pour cette rémunération.
Un tel système à grande échelle amènera, sans aucun doute, des "super conglomérats" qui vont centraliser l'acquisition des ressources des autres. Résultat, le dividende universel ne servira jamais à rien, car quelque soit le montant, le prix des services de base augmentera en conséquence, le DU ne sera jamais suffisant.

C'est l'exemple des APL prévues initialement pour permettre l'accès à des logements de meilleurs qualités et qui, au final après quelques mois, sont principalement absorbés par les propriétaires qui ont augmentés les loyers du montant des APL.

Bref, il est absolument nécessaire que le mécanisme de la monnaie empêche ce comportement. Il ne faut pas une autre monnaie cupide.

J'adore ce que fait Snips, c'est vraiment au top, clair, bien développé.

Pourriez-vous également fournir un modèle pseudo-complet de toutes les phrases-types classiques ?
Car le code sans modèle ne sert pas à grand chose et le modèle avec 3 phrases pour la météo, même s'il marche, ne sert pas à grand chose.

À ce que j'ai compris, vous avez comparé votre réseau pour le NLU aux autres "grands" gaffeurs du domaine, je déduis donc que vous devez avoir des corpus super gros pour ça. Pouvez-vous les partager? Sinon, connaissez-vous un lien vers de tel corpus libre, pour le français?

Dans la même veine, Mozilla common voice est en train de finaliser sa version internationale pour le projet Common Voice, se qui devrait permettre d'avoir, très bientôt j'espère, un corpus d'audio + transcription libre en Français.

Car pour faire un assistant libre, il faut, certes, du code libre, mais des modèles libres. Aujourd'hui la partie STT (speech to text) est majoritairement basée sur Kaldi. Seulement, impossible de trouver des modèles libres en Français pour Kaldi. Kaldi n'est pas non plus au top en terme de WER (en comparaison de la concurrence). C'est l'oeuf et la poule, tant qu'il n'y a pas de modèle libre, Kaldi n'est utilisé que pour du prototypage/recherche, et donc ne concerne que les pros du domaines. Du coup, il n'y a pas l'effet de masse qui inciterait des milliers de développeurs à améliorer Kaldi pour atteindre les performance d'un Google API.

Avec un WER de 9% (c'est déjà très très bien), ça veut dire que l'engine NLU doit pouvoir marcher correctement avec 1 mot sur 11 pourri. Comment tester ça dans votre code sans modèle ?

Oui, mais c'est lourd à écrire, à lire et donc à maintenir. C'est ça le problème.

Certes, mais en même temps, exposer dans ta sérialisation le nom du membre (côté programme) est vraisemblablement une mauvaise idée.

Je comprends ta remarque, mais ce dont tu parles c'est d'avoir la possibilité de filtrer le "nom" des membres. L'un n'empêche pas l'autre. Dans 95% des cas, tu veux un 1:1 entre la sérialisation et ta classe, donc le code devrait pouvoir faire cela directement, et pour les 5% restant, tu peux intercepter et/ou filtrer. La proposition d'introspection (qui sera dans C++20 probablement) le permettra justement.

Ça c’est une très mauvaise idée. Si j’appelle un membre qui n’existe pas, je m’attends à une erreur de compilation, pas une erreur à l’exécution. Changer ça dans le contexte de C++, c’est, quelque part, casser le langage.

Justement, c'est tout l'intérêt du constexpr ici. Par défaut, un tel opérateur entraînerait une erreur "membre machin non trouvé" donc le comportement sera 100% identique à l'état actuel.
Par contre, si l'opérateur est présent, alors soit il est constexpr et peut être vérifié à la compilation (donc un comportement entre le mode dynamique/runtime et le mode figé/statique).
Ceci serait très utile justement pour éviter les "outils" de génération qui écrivent du code illisible (type mock ou autre gsoap).
Exemple d'application, les membres namespace:attribute du XML, l'opérateur pourrait vérifier que le nom du membre "inconnu" que l'on veut vérifier commence par le nom du namespace attendu, par exemple.
Ou que les membres ajoutés commencent par "signal_" ou "slot_", si tu vois ce que je veux dire.

Ensuite, si l'opérateur n'est pas constexpr, le compilateur pourrait te jeter pour chaque appel dont le nom du membre est fixe à la compilation (avec un warning du genre "Ce serait mieux si tu ajoutais un membre machin à ta classe").

Enfin, tu l'utilises comme une classe dynamique au runtime (donc tu ne connais pas le nom des membres à priori), et tu utilises l'introspection pour les retrouver. C'est faisable actuellement avec une table de hash, mais c'est pas natif, donc pas optimal.

En bref, tu as le choix, c'est justement ça pour moi l'intérêt principal du C++

Je suis tout à fait d'accord. Concernant la POO, le standard C++17 n'apporte rien de transcendant. Franchement, avoir des fonctionnalités d'introspection en 2017, je ne pense pas que ce soit si superflu (à l'heure où quasiment toute donnée est transmise en JSON). Il n'y a pas une seule bibliothèque C++ aujourd'hui qui sache faire de la sérialisation sans avoir à déclarer chaque champs 2 fois (une fois pour la compilation "statique" et une fois pour le runtime). C'est assez pénible.

De même, avoir des objets dynamiques, sans se taper des tuple à rallonge qui sont vraiment mauvais niveau praticité et performance et maintenabilité, à part pour la performance, c'est franchement manquant. Alors qu'il suffirait d'ajouter un opérateur pour "membre non trouvé" à gérer au runtime, du genre

  struct MyClass {
      int foo;
      string bar;
      runtime_members __otherMembers; // A bit like a map<any>

      template <class T> any operator .(const string & name, const T & arg ) { return __otherMembers[name] = arg; }
  };

  MyClass a;
  a.foo = 3;
  a.bar = "hello";
  a.baz = "world"; // call operator .
  a.qux = 4.5;     // ditto

Lorsque le compilateur rencontrerait un membre non présent, il appellerait l'opérateur "." (qui peut static_asserter si le nom n'est pas acceptable, ou remplir les champs au runtime.